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DESCRIPTION 

METHOD AND SYSTEM FOR MOBILE COMMUNICATIONS 

TECHNICAL FIELD 
The present invention generally relates to a method and system for mobile 
communication and especially relates to a method and system adopted to transmission 
of various sorts of data in accordance with the development of multimedia. 

BACKGROUND ART 

Conventionally, portable telephones have been widely spread, and TDMA 
(time division multiple access) and FDMA (frequency division multiple access) were 
used for access methods for portable telephones. In these days, CDMA (code division 
multiple access) is being adopted instead of TDMA and FDMA because of various 
merits, such as high efficiency at usage of frequency band, facility of change of 
transmission rate, and preservation from eavesdropping. 

However, CDMA according to prior art is prepared mainly for voice 
transmission and therefore is not suitable for data communication. In recent years, 
as the development of multimedia, not only voice but also various kinds of data that 
can be processed in computers and so on should be transmitted. Therefore, 
communication access between mobile stations and network should be suitable for 
transmitting various types of data in the near future. 

DISCLOSURE OF INVENTION 

It is therefore an object of the present invention to provide a method and . 
system for mobile communication suitable for transmitting various types of data in 
accordance with the development of multimedia. 

The present invention provides a method for mobile communication carried 
out among a plurality of mobile stations and a network, personal identifiers being 
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previously and respectively assigned to the mobile stations, the method comprising the 
steps of: assigning temporary identifiers respectively to mobile stations which are 
communicable with the network; storing the personal identifiers and the temporary 
identifiers of the mobile stations by the network; storing the personal identifier and 
5 the temporary identifier of each mobile station by the mobile station; detecting by the 
network that one of the temporary identifiers stored in itself is different from that 
stored in the corresponding mobile station; and reassigning by the network another 
temporary identifier to the mobile station of which the former temporary identifier 
stored in the network is detected to be different from that stored in the corresponding 

10 mobile station. 

By virtue of the above invention, it is possible to provide a method and system 
for CDMA wireless communication suitable for transmitting various types of data in 
accordance with the development of multimedia. 

The present invention provides a base station controller communicating with 

15 a mobile station, which is able to conduct diversity reception, via a plurality of radio 
base stations under control of a switching center, the controller comprising enciphering 
means for enciphering transmitted information, which has been received from the 
switching center and should be transmitted to the mobile station, so as to generate 
enciphered transmitted information. 

20 In addition, the present invention provides a base station controller 

communicating with a mobile station, which is able to conduct diversity reception, via 
a plurality of radio base stations under control of a switching center, the controller 
comprising: retransmission-control-information-adding means for adding 
retransmission control information to enciphered transmitted information which has 

25 been previously enciphered by the switching center; and transmitting means for 
transmitting the enciphered transmitted information with the retransmission control 
information to the radio base stations. 

Additionally, the present invention provides a switching center 
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communicating with a mobile station, which is able to conduct diversity reception, via 
a plurality of radio base stations and a base station controller, the switching center 
comprising enciphering means for enciphering transmitted information, which should 
be transmitted to the mobile station, so as to generate enciphered transmitted 
5 information. 

In addition, the present invention provides a system for mobile 
communication including a mobile station which is able to conduct diversity reception, 
a plurality of radio base stations, and a base station controller communicating via the 
radio base stations under control of a switching center, the system being characterized 

10 in that the base station controller enciphers information, which should be transmitted 
from the side of the switching center to the side of the mobile station, before 
distributing the information to the radio base stations. 

Additionally, the present invention provides a system for mobile 
communication including a mobile station which is able to conduct diversity reception, 

15 a plurality of radio base stations, and a base station controller communicating via the 
radio base stations under control of a switching center, the system being characterized 
in that the switching center enciphers information, which should be transmitted from 
the side of the switching center to the side of the mobile station, before distributing the 
information to the radio base stations. 

20 In addition, the present invention provides a system for mobile 

communication including a mobile station which is able to conduct diversity reception, 
a plurality of radio base stations, and a base station controller communicating via the 
radio base stations under control of a switching center, the system comprising layer-2- 
enciphering-means for enciphering information that should be processed only in one or 

25 more layers which are the same as or higher than layer 2 of the OSI reference model. 

Additionally, the present invention provides a system for mobile 
communication including a mobile station which is able to conduct diversity reception, 
a plurality of radio base stations, and a base station controller communicating via the 
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radio base stations under control of a switching center, the system comprising: layer- 
3-enciphering-means for enciphering information that should be processed only in one 
or more layers which are the same as or higher than layer 3 of the OSI reference 
model; and layer-2-mutual-notifying-means for facilitating notification between layers 
5 of different devices corresponding to layer 2 of the OSI reference model about an onset 
of transmission of enciphered information. 

Furthermore, the present invention provides a system for mobile 
communication including a mobile station which is able to conduct diversity reception, 
a plurality of radio base stations, and a base station controller communicating via the 
10 radio base stations under control of a switching center, the system comprising: layer- 
3-enciphering-means for enciphering information that should be processed only in one 
or more layers which are the same as or higher than layer 3 of the OSI reference 
model; retransmission-control-information-adding means, at a layer corresponding to 
layer 2 of the OSI reference model, for adding retransmission control information to 
15 information which has been previously enciphered by the layer-3-enciphering means; 
and transmitting means for transmitting the enciphered transmitted information with 
the retransmission control information to the radio base stations. 

In addition, the present invention provides a method for controlling a base 
station controller communicating with a mobile station, which is able to conduct 
20 diversity reception, via a plurality of radio base stations under control of a switching 
center, the system for mobile communication comprising the step of enciphering 
transmitted information, which has been received from the switching center and 
should be transmitted to the mobile station, so as to generate enciphered transmitted 
information. 

25 Furthermore, the present invention provides a method for controlling a base 

station controller communicating with a mobile station, which is able to conduct 
diversity reception, via a plurality of radio base stations under control of a switching 
center, the method comprising the steps of: adding retransmission control information 
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to enciphered transmitted information which has been previously enciphered by the 
switching center; and transmitting the enciphered transmitted information with the 
retransmission control information to the radio base stations. 

Furthermore, the present invention provides a method for controlling a 
5 switching center communicating with a mobile station, which is able to conduct 
diversity reception, via a plurality of radio base stations and a base station controller, 
the method comprising the step of enciphering transmitted information, which should 
be transmitted to the. mobile station, so as to generate enciphered transmitted 
information. 

10 Additionally, the present invention provides a method for controlling a system 

for mobile communication including a mobile station which is able to conduct diversity 
reception, a plurality of radio base stations, and a base station controller 
communicating via the radio base stations under control of a switching center, the 
method comprising the step of, at the base station controller, enciphering information, 

15 which should be transmitted from the side of the switching center to the side of the 
mobile station, before transmitting the information to the base station controller. 

Furthermore, the present invention provides a method for controlling a 
system for mobile communication including a mobile station which is able to conduct 
diversity reception, a plurality of radio base stations, and a base station controller 

20 communicating via the radio base stations under control of a switching center, the 
method comprising the step of, at the switching center, enciphering information, which 
should be transmitted from the side of the switching center to the side of the mobile 
station, before distributing the information to the radio base stations. 

In addition, the present invention provides a method for controlling a system 

25 for mobile communication including a mobile station which is able to conduct diversity 
reception, a plurality of radio base stations, and a base station controller 
communicating via the radio base stations under control of a switching center, the 
method comprising the step of enciphering information that should be processed only 
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in one or more layers which are the same as or higher than layer 2 of the OSI reference 
model. 

Additionally, the present invention provides a method for controlling a system 
for mobile communication including a mobile station which is able to conduct diversity 
5 reception, a plurality of radio base stations, and a base station controller 
communicating via the radio base stations under control of a switching center, the 
method comprising the steps of: enciphering information that should be processed only 
in one or more layers which are the same as or higher than layer 3 of the OSI reference 
model; and facilitating notification between layers of different devices corresponding to 
10 layer 2 of the OSI reference model about an onset of transmission of enciphered 
information. 

The present invention provides a method for controlling a system for mobile 
communication including a mobile station which is able to conduct diversity reception, 
a plurality of radio base stations, and abase station controller communicating via the 

15 radio base stations under control of a switching center, the method comprising the 
steps of: enciphering information that should be processed only in one or more layers 
which are the same as or higher than layer 3 of the OSI reference model; adding 
retransmission control information at a layer corresponding to layer 2 of the OSI 
reference model to information which has been previously enciphered by the 

20 enciphering step; and transmitting the enciphered transmitted information with the 
retransmission control information to the radio base stations. 

By virtue of the invention as described above, it is possible for a mobile station 
to conduct diversity reception although the mobile station cannot simultaneously 
process enciphered transmission signal and non -enciphered transmission signal. 

25 In addition, the present invention provides a mobile station communicating 

with a network over the air, comprising decipherment-onset-time-setting-means for 
setting a time to start deciphering an enciphered reception signal dependently on a 
time to start enciphering a transmission signal in the network and independently of a 
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time to start enciphering a transmission signal in the mobile station. 

Furthermore, the present invention provides a mobile station further 
comprising deciphering means for deciphering an enciphered reception signal received 
from the network over the air, the decipherment-onset-time-setting-means including 
encipherment-onset-request-determining means for determining if a reception 
encipherment onset request is received from the network or not; and decipherment- 
instructing means for instructing the deciphering means to start deciphering in 
accordance with a time when the reception encipherment onset request has been 
received on the basis of the determination. 

Additionally, the present invention provides a mobile station communicating 
with a network over the air, comprising encipherment-onset-time-setting-means for 
setting a time to start enciphering a transmission signal independently of a time to 
start deciphering an enciphered reception signal. 

Furthermore, the present invention provides a mobile station further 
comprising transmission-encipherment-onset-requesting means for transmitting a 
transmission encipherment onset request to the network over the air; and enciphering 
means for enciphering the transmission signal so as to generate an enciphered 
transmission signal, the encipherment-onset-time-setting-means including 
encipherment-instructing means for instructing the enciphering means to start 
enciphering in accordance with a time when the transmission encipherment onset 
request has been transmitted. 

In addition, the present invention provides a controller in a network 
communicating with a mobile station over the air, comprising decipherment-onset- 
time-setting-means for setting a time to start deciphering an enciphered reception 
signal dependently on a time to start enciphering a transmission signal in the mobile 
station and independently of a time to start enciphering a transmission signal in the 
controller. 

Furthermore, the present invention provides a controller in a network further 
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comprising deciphering means for deciphering an enciphered reception signal received 
from the mobile station over the air, the decipherment-onset-time-setting-means 
including encipherment-onset-request-determining means for determining if a 
reception encipherment onset request is received from the network or not; and 
5 decipherment-instructing means for instructing the deciphering means to start 
deciphering in accordance with a time when the reception encipherment onset request 
has been received on the basis of the determination. 

The present invention provides a controller in a network communicating with 
a mobile station over the air, comprising encipherment-onset-time-setting-means for 

10 setting a time to start enciphering a transmission signal independently of a time to 
start deciphering an enciphered reception signal. 

Furthermore, the present invention provides a controller in a network further 
comprising transmission-encipherment-onset-requesting means for transmitting a 
transmission encipherment onset request to the mobile station over the air; and 

15 enciphering means for enciphering the transmission signal so as to generate an 
enciphered transmission signal, the enciphermerit-onset-time-setting-means including 
encipherment-instructing means for instructing the enciphering means to start 
enciphering in accordance with a time when the transmission encipherment onset 
request has been transmitted. 

20 Additionally, the present invention provides a system for mobile 

communication comprising a mobile station and a network communicating with each 
other over the air, 

the network comprising: encipherment-onset-requesting means for 
transmitting an encipherment onset request to the mobile station over the air; first- 
25 enciphered-transmission-signal-generating means for enciphering a first transmission 
signal which should be transmitted from the network to the mobile station after the 
transmission of the encipherment onset request, thereby generating a first enciphered 
transmission signal; first-enciphered-transmission-signal-transmitting means for 
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transmitting the first enciphered transmission signal to the mobile station; response 
determining means for determining if an encipher onset response by the mobile station 
indicating that the encipherment onset request is acceptable is received or not; and 
first deciphering means for starting to decipher a second enciphered transmission 
5 signal from the mobile station on the basis of the determination of the response 
determining means when the mobile station accepts the encipherment onset request, 

the mobile station comprising: request determining means for determining if 
the encipherment onset request is received or not; encipherment-onset-responding 
means for transmitting the encipherment onset response on the basis of the 

10 determination of the request determining means when the encipherment onset request 
is accepted; second deciphering means for starting to decipher the first enciphered 
transmission signal from the network when the encipherment onset request is 
accepted; second-enciphered-transmission-signal-generating means for enciphering a 
second transmission signal which should be transmitted from the mobile station to the 

15 network after the transmission of the encipherment onset response, thereby 
generating a second enciphered transmission signal; and second-enciphered- 
transmission-signal-transmitting means for transmitting the second enciphered 
transmission signal to the network. 

In addition, the present invention provides a method for controlling a mobile 

20 station communicating with a network over the air, comprising the step of setting a 
time to start deciphering an enciphered reception signal dependently on a time to start 
enciphering a transmission signal in the network and independently of a time to start 
enciphering a transmission signal in the mobile station. 

Furthermore, the present invention provides a method for controlling a mobile 

25 station, further comprising the step of deciphering an enciphered reception signal 
received from the network over the air, the step of setting a time to start deciphering 
including the steps of determining if a reception encipherment onset request is 
received from the network or not; and instructing to start the deciphering step in 
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accordance with a time when the reception encipherment onset request has been 
received on the basis of the determination. 

Additionally, the present invention provides a method for controlling a mobile 
station communicating with a network over the air, comprising the step of setting a 
5 time to start enciphering a transmission signal independently of a time to start 
deciphering an enciphered reception signal. 

Furthermore, the present invention provides a method for controlling a mobile 
station, further comprising the steps of transmitting a transmission encipherment 
onset request to the network over the air; and enciphering the transmission signal so 
10 as to generate an enciphered transmission signal, the step of setting a time to start 
enciphering including the step of instructing to start the enciphering step in 
accordance with a time when the transmission encipherment onset request has been 
transmitted. 

In addition, the present invention provides a method for controlling a 
15 controller in a network communicating with a mobile station over the air, comprising 
the step of setting a time to start deciphering an enciphered reception signal 
dependently on a time to start enciphering a transmission signal in the mobile station 
and independently of a time to start enciphering a transmission signal in the 
controller. 

20 Furthermore, the present invention provides a method for controlling a 

controller in a network further comprising the step of deciphering an enciphered 
reception signal received from the mobile station over the air, the step of setting a time 
to start deciphering including the steps of determining if a reception encipherment 
onset request is received from the network or not; and instructing to start the 

25 deciphering step in accordance with a time when the reception encipherment onset 
request has been received on the basis of the determination: 

Additionally, the present invention provides a method for controlling a 
controller in a network communicating with a mobile station over the air, comprising 
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the step of setting a time to start enciphering a transmission signal independently of a 
time to start deciphering an enciphered reception signal. 

Furthermore, the present invention provides a method for controlling a 
controller in a network further comprising the steps of transmitting a transmission 
encipherment onset request to the mobile station over the air; and enciphering the 
transmission signal so as to generate an enciphered transmission signal, the step of 
setting a time to start enciphering including the step of instructing to start the 
enciphering step in accordance with a time when the transmission encipherment onset 
request has been transmitted. 

In addition, the present invention provides a method for controlling a system 
for mobile communication in which a mobile station and a network communicate with 
each other over the air, the method comprising the steps of: transmitting an 
encipherment onset request from the network to the mobile station over the air; 
enciphering a first transmission signal which should be transmitted from the network 
to the mobile station after the transmission of the encipherment onset request, thereby 
generating a first enciphered transmission signal; transmitting the first enciphered 
transmission signal to the mobile station; determining if an encipher onset response by 
the mobile station indicating that the encipherment onset request is acceptable is 
received or not; starting to decipher a second enciphered transmission signal from the 
mobile station on the basis of the determination of the response determining step when 
the mobile station accepts the encipherment onset request; determining if the 
encipherment onset request is received or not; transmitting the encipherment onset 
response on the basis of the determination of the request determining step when the 
encipherment onset request is accepted; starting to decipher the first enciphered 
transmission signal from the network when the encipherment onset request is 
accepted; enciphering a second transmission signal which should be transmitted from 
the mobile station to the network after the transmission of the encipherment onset 
response, thereby generating a second enciphered transmission signal; and 
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transmitting the second enciphered transmission signal to the network. 

By virtue of the aspects of the invention as set forth, although the structural 
elements in the network are not provided with the function to read both of enciphered 
and non-enciphered signals simultaneously as simplifying the system, the timing of 
the encipherment onset is aligned in the base station and the network, so that the 
communication between the mobile station and the network can be facilitated surely 
and smoothly. 

Additionally, the present invention provides a mobile station communicating 
with a network over the air, comprising encipherment-procedure-notifying-means for 
notifying the network about encipherment-procedure-specifying-information 
specifying one or more possible encipherment procedures of the mobile station. 

Furthermore, the present invention provides a mobile station, wherein the 
encipherment-proce dure -notify ing-me ans further including enciphering-key - 
generation-procedure-notifying-means for notifying the network about enciphering- 
key-generation-procedure-specifying-information specifying one or more possible 
enciphering key generation procedures of the mobile station. 

In addition, the present invention provides a mobile station communicating 
with a network over the air, comprising encipherment communication means for 
conducting an encipherment procedure corresponding to an encipherment request 
given by the network and for communicating with the network. 

Furthermore, the present invention provides a mobile station, wherein the 
encipherment communication means includes enciphering-key-generating-means for 
generating an enciphering key corresponding to enciphering-key-generation- 
procedure-specifying-means specifying an enciphering key generation procedure 
notified by the network; and enciphering means for conducting an encipherment 
procedure using the enciphering key generated by the enciphering-key-generating- 
means. 

Additionally, the present invention provides a controller in a network 
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communicating with a mobile station over the air, comprising encipherment- 
procedure-selecting means for selecting an encipherment procedure for communication 
in accordance with encipherment-procedure-specifying-information, specifying one or 
more possible encipherment procedures of the mobile station, notified by the mobile 
station; and encipherment requesting means for notifying the mobile station about an 
encipherment request requesting the mobile station to conduct an encipherment using 
the encipherment procedure selected by the encipherment-proce dure -selecting means. 

Furthermore, the present invention provides a controller in a network further 
comprising enciphering-key-generation-procedure-selecting-means for selecting an 
enciphering key generation procedure in accordance with encip he ring-key- generation- 
procedure-specifying-information, specifying one or more possible encipherment 
procedures of the mobile station, notified by the mobile station; and enciphering-key- 
notifying means for notifying the base station about the enciphering key generation 
procedure selected by the enciphering-key-generation-procedure-selecting-means. 

By virtue of the aspects of the invention as set forth, it is possible to select the 
encipherment procedure adapted to the security level instructed by the mobile station 
or the mobile station user, thereby conducting the encipherment procedure. It is also 
possible select the encipherment procedure adapted to the multimedia service for 
transporting voice or moving picture from the mobile station or the network, thereby 
conducting the encipherment procedure. Furthermore, if it is necessary to enhance 
the security level for future extension of communication systems and for newly 
executed services, it will be possible to readily introduce a newly developed 
encipherment procedure. In addition, if a plurality of networks are provided with the 
ability for conducting one or more common encipherment procedures, it is possible to 
conduct one of the encipherment procedures when the mobile station roams across the 
service areas of the networks although all of the possible encipherment procedures are 
not commonly shared. Even in this case, it is also possible in each network to conduct 
one or more original encipherment procedures. 
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The present invention provides a method for controlling access links between 
a mobile station and a network, characterized in that a plurality of branches are 
established between the network and the mobile station upon a call attempt to or from 
the mobile station located at a position where the mobile station can communicate 
5 using diversity handover, the plurality of branches including a main branch and at 
least one auxiliary branch for additional use in order that the mobile station may 
communicate using diversity handover, thereby enabling the mobile station to 
commence the diversity handover using the plurality of branches. 

In addition, the present invention provides a mobile station characterized in 
10 that it establishes a plurality of branches between the network and the mobile station 
upon the reception of a message from the network when no access link is established 
between the network and the mobile station, the message including a request for 
establishing the branches, thereby commencing the diversity handover using the 
plurality of branches. 

15 Additionally, the present invention provides a base station controller 

characterized in that it establishes a plurality of branches between a network and a 
mobile station upon a call attempt to or from the mobile station at a location where the 
mobile station can communicate using diversity handover, the plurality of branches 
including a main branch and at least one auxiliary branch for additional use in order 

20 that the mobile station may communicate using diversity handover. 

In addition, the present invention provides a base station controller 
characterized in that it transmits a message to both of a base station and a mobile 
station upon a call attempt to or from the mobile station at a location where the mobile 
station can communicate by means of intra-cell diversity handover wherein the mobile 

25 station and the base station communicate with each other using a plurality of 
branches, the message including a request for establishing a plurality of branches 
including a main branch and at least one auxiliary branch for additional use in order 
that the mobile station may communicate by means of intra-cell diversity handover. 
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Additionally, the present invention provides a base station controller 
characterized in that it transmits a message to a plurality of base stations upon a call 
attempt to or from the mobile station at a location where the mobile station can 
communicate by means of inter-cell diversity handover wherein the mobile station 
5 communicates with the plurality of base stations, the message including a request for 
establishing a plurality of branches between the mobile station and the corresponding 
base stations. 

In addition, the present invention provides a base station characterized in 
that it establishes a plurality of branches between the base station and the mobile 

10 station according to an instruction from a base station controller upon a call attempt to 
or from the mobile station at a location where the mobile station can communicate by 
means of intra-cell diversity handover wherein the mobile station and the base station 
communicate with each other using the plurality of branches, the plurality of branches 
including a main branch and at least one auxiliary branch for additional use in order 

15 that the mobile station may communicate by means of intra-cell diversity handover, 
thereby enabling the mobile station to commence the intra-cell diversity handover. 

By virtue of the aspects of the invention as set forth, when there is the mobile 
station at a location where it can communicate by means of intra-cell diversity 
handover wherein the mobile station and the base station communicate with each 

20 other using the plurality of branches, a series of procedures for establishing the main 
branch and for adding the auxiliary branch can be carried out upon the call attempt to 
or from the mobile station. Therefore, the number of signal flows can be reduced, so 
that it is possible to transit diversity handover condition efficiently and to decrease the 
interference to other radio access links. 

25 The present invention provides a method for controlling a branch replacement 

characterized in that at least a current branch between a network and a mobile station 
are replaced with a plurality of branches necessary for communication using diversity 
handover when the branch replacement is necessary for the mobile station and when it 
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is recognized that the mobile station can commence communicating using diversity 
handover if the branch replacement is carried out, thereby enabling the mobile station 
to commence diversity handover. 

Additionally, the present invention provides a mobile station characterized in 
5 that it replaces at least a current branch between a network and the mobile station 
with a plurality of branches necessary for communication using diversity handover 
when a branch replacement is necessary for the mobile station and when the mobile 
station can commence communicating using the diversity handover branches if the 
branch replacement is carried out, thereby commencing diversity handover. 

10 In addition, the present invention provides a base station controller 

characterized in that it replaces at least a current branch between a network and a 
mobile station with a plurality of branches necessary for communication using 
diversity handover when a branch replacement is necessary for the mobile station and 
when it is recognized that the mobile station can commence communicating using 

15 diversity handover if the branch replacement is carried out, thereby enabling the 
mobile station to commence diversity handover. 

Additionally, the present invention provides a base station controller 
characterized in that it transmits a message to a base station and a mobile station 
when a branch replacement is necessary for the mobile station and when it is 

20 recognized that, if the branch replacement is carried out, the mobile station can 
commence communicating by means of intra-cell diversity handover wherein the 
mobile station and the base station communicate with each other using a plurality of 
branches, the message including an instruction to carry out the branch replacement 
and an instruction to add at least one auxiliary branch for additional use in order to 

25 communicate using diversity handover. 

In addition, the present invention provides a base station controller 
characterized in that it transmits an instruction to a plurality of base stations and a 
message to a mobile station when a branch replacement is necessary for the mobile 
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station and when it is recognized that the mobile station can commence 
communicating by means of inter-cell diversity handover if the branch replacement is 
carried out, the instruction instructing the base stations to set branches necessary for 
the diversity handover, the message including an instruction to carry out the branch 
replacement and an instruction to add at least one auxiliary branch for additional use 
in order to communicate using diversity handover. 

Additionally, the present invention provides a base station characterized in 
that it replaces a branch for a mobile station and adds at least one auxiliary branch for 
the mobile station according to instructions of a message once the base station receives 
the message from a base station controller, the message including an instruction to 
carry out branch replacement and an instruction to add at least one auxiliary branch 
for additional use in order to communicate using diversity handover, thereby 
commencing the intra-cell diversity handover. 

The aspects of the invention as set forth replaces the current branch or 
branches with the branches adapted to diversity handover upon a trigger for the 
branch replacement when it is recognized that the diversity handover can be 
commenced if the branch replacement is conducted. Therefore, the number of signal 
flows can be reduced, so that it is possible to transit diversity handover condition 
efficiently and to decrease the interference to other radio access links. 

The present invention provides a branch controlling method for a mobile 
station capable of treating a plurality of calls simultaneously, characterized in that 
when a new call occurs while the mobile station treats an existent call, at least either 
of branch structures for both of the calls or at least either of communication frequency 
bands for both of the calls is controlled, so that the branch structures are the same as 
each other and the communication frequency bands are the same as each other. 

In addition, the present invention provides a branch controlling method for a 
mobile station capable of treating a plurality of calls simultaneously, characterized in 
that when a new call occurs while the mobile station treats an existent call, a branch 
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structure and a communication frequency band being the same as those for the 
existent call are assigned to the new call. 

Additionally, the present invention provides a mobile station capable of 
treating a plurality of calls simultaneously, characterized in that when a new call 
5 occurs while the mobile station treats an existent call, the mobile station uses a branch 
structure being the same as that for the existent call to the new call and a 
communication frequency band being the same as that for the existent call to the new 
call in accordance with an instruction from a network. 

In addition, the present invention provides a base station controller adapted 

10 for a mobile station capable of treating a plurality of calls simultaneously, 
characterized in that when a new call occurs while the mobile station treats an 
existent call, the base station controller controls at least either of branch structures for 
both of the calls or at least either of communication frequency bands for both of the 
calls, so that the branch structures are the same as each other and the communication 

15 frequency bands are the same as each other. 

Additionally, the present invention provides a base station controller adapted 
for a mobile station capable of treating a plurality of calls simultaneously, 
characterized in that when a new call occurs while the mobile station treats an 
existent call, the base station controller assigns a branch structure and a 

20 communication frequency band being the same as that for the existent call to the new 
call. 

By virtue of the aspects of the invention as set forth, it is possible to assigns 
the same branch structure and the same frequency band for the plurality of calls 
including the existent and new calls, so as to ease the control for both of the calls. 
25 The present invention provides a branch controlling method adapted for a 

mobile station capable of treating a plurality of calls simultaneously, characterized in 
that when a new call occurs while the mobile station treats an existent call and when it 
is impossible to assign a branch structure or a communication frequency band, being 
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the same as the branch structure or the communication frequency band for the 
existent call, to the new call, another branch structure or another communication 
frequency band which can continue both of the existent and new calls is selected, and 
the selected branch structure or communication frequency band is assigned to both of 
5 the existent and new calls. 

The present invention provides a mobile station capable of treating a plurality 
of calls simultaneously, characterized in that when a new call occurs while the mobile 
station treats an existent call and when it is impossible to assign a branch structure or 
a communication frequency band, being the same as the branch structure or the 

10 communication frequency band for the existent call, to the new call, the mobile station 
assigns another branch structure or another communication frequency band, which 
can continue both of the existent and new calls, to both of the existent and new calls in 
accordance with an instruction from a network. 

The present invention provides a base station controller adapted for a mobile 

15 station capable of treating a plurality of calls simultaneously, characterized in that 
when a new call occurs while the mobile station treats an existent call and when it is 
impossible to assign a branch structure or a communication frequency band, being the 
same as the branch structure or the communication frequency band for the existent 
call, to the new call, the base station controller selects another branch structure or 

20 another communication frequency band which can continue both of the existent and 
new calls, and assigns the selected branch structure or communication frequency band 
to both of the existent and new calls. 

By virtue of the aspects of the invention as set forth, it is possible to assigns 
the same branch structure and the same frequency band for the plurality of calls 

25 including the existent and new calls, so as to ease the control for both of the calls. 

The present invention provides a branch controlling method adapted for a 
mobile station, characterized in that when a trigger of handover occurs to the mobile 
station which is treating a plurality of calls, a branch structure or a communication 
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frequency band which can continue all of the calls is selected, and the selected branch 
structure or communication frequency band are assigned to all of the calls commonly. 

The present invention provides a mobile station capable of treating a plurality 
of calls simultaneously, characterized in that when a trigger of handover occurs to the 
5 mobile station which is treating a plurality of calls, the mobile station, according to an 
instruction from a network, alters a branch structure or a communication frequency 
band for all of the calls to a new branch structure or a new communication frequency 
band for all of the calls commonly. 

The present invention provides a base station controller adapted for a mobile 
v3 10 station, characterized in that when a trigger of handover occurs to the mobile station 

Q which is treating a plurality of calls, the base station controller selects a branch 

structure or a communication frequency band which can continue all of the calls, and 
12 assigns the selected branch structure or communication frequency band to all of the 

JL calls commonly. 

iH. 15 By virtue of the aspects of the invention as set forth, it is possible to assigns 

W the same branch structure and the same frequency band for the plurality of calls 

Q during communicating although handover is carried out, so as to ease the control for 

all of the calls. 

The present invention provides a branch controlling method adapted for a 
20 mobile station, characterized in that when a trigger of handover occurs to the mobile 
station which is treating a plurality of calls and when there is not a branch structure 
which can continue all of the calls in relation to the mobile station or when there is not 
a communication frequency band which can continue all of the calls in relation to the 
mobile station, another branch structure or another communication frequency band 
25 which can continue a plurality of calls being high in priority among the calls are 
selected; the other call or calls are released; and the selected branch structure and 
communication frequency band are assigned to the priority calls. 

In addition, the present invention provides a mobile station characterized in 
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that when a trigger of handover occurs to the mobile station which is treating a 
plurality of calls and when there is not a branch structure which can continue all of the 
calls in relation to the mobile station or when there is not a communication frequency 
band which can continue all of the calls in relation to the mobile station, the mobile 
5 station, according to an instruction from a network, releases a call or calls being low in 
priority; and assigns a branch structure and a communication frequency band selected 
by the network to a plurality of calls being high in priority. 

Additionally, the present invention provides a base station controller adapted 
for a mobile station, characterized in that when a trigger of handover occurs to the 

10 mobile station which is treating a plurality of calls and when there is not a branch 
structure which can continue all of the calls in relation to the mobile station or there is 
not a communication frequency band which can continue all of the calls in relation to 
the mobile station, the base station controller selects another branch structure and 
another communication frequency band which can continue a plurality of calls being 

15 high in priority among the calls; releases the other call or calls; and assigns the 
selected branch structure and communication frequency band to the priority calls. 

* By virtue of the aspects of the invention as set forth, it is possible to continue 
the calls with a high priority when the trigger for handover occurs although there are 
not a branch structure and a communication frequency band which can continue all of 

20 the calls. In other words, it is possible to continue at least the calls with a high 
priority although there are not ample wireless communication resources. 

In addition, the present invention provides a method for establishing a control 
channel in a mobile communication system wherein a mobile station treats a plurality 
of calls using a plurality of sets of wireless communication resources, characterized in 

25 that a single control channel is established between the mobile station and a network 
for transporting control information therebetween in a manner that the control 
channel is formed by one of the sets of wireless communication resources which are 
being used for a plurality of calls by the mobile station. 
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By virtue of the invention, it is possible to reduce the number of hardware 
elements for transporting control information in comparison with the case that all of 
the plurality of calls utilize control channels, respectively. In addition, it is possible to 
exclude complicated control procedures, e.g., management of the transportation order 
of control information in the plurality of control channels. 

Additionally, the present invention provides a method for controlling to 
replace a control channel, characterized in that while a mobile station treats a 
plurality of calls using a plurality of sets of wireless communication resources and 
transmits or receives control information to or from a network via a single control 
channel formed by one of the sets of the wireless communication resources, and when a 
first call using the control channel formed by one of the sets of the wireless 
communication resources should be released and a second call should be continued, the 
control channel, which is formed by one of the sets of the wireless communication 
resources and should be released, is replaced with a new control channel formed by 
another set of the wireless communication resources, thereby continuing to control the 
second call. 

In addition, the present invention provides a base station controller, 
characterized in that while a mobile station treats a plurality of calls using a plurality 
of sets of wireless communication resources and transmits or receives control 
information to or from a network via a control channel formed by one of the sets of the 
wireless communication resources, and when a first call using the control channel 
formed by one of the sets of the wireless communication resources should be released 
and a second call should be continued, the controller replaces the control channel, 
which is formed by one of the sets of the wireless communication resources and should 
be released, to a new control channel formed by another set of the wireless 
communication resources, thereby continuing to control the second call. 

By virtue of the aspects of the invention as set forth, while a mobile station 
transmits or receives control information with respect to a plurality of calls via a 



F0220/2551 



23 

common control channel, and when a first call using the control channel formed by one 
of the sets of the wireless communication resources should be released and a second 
call should be continued by means of another set of the wireless communication 
resources, the control channel is replaced. Accordingly, after the replacement, by 
means of the new control channel, it is possible to continue the transportation of 
control signal for the second call. 

The present invention provides a method for determining a radio zone and an 
uplink transmission power, characterized in that 

each of base stations transmits broadcast information indicating a perch 
channel transmission power level and an uplink interference level via a corresponding 
perch channel; and 

a mobile station receives the broadcast information from near base stations 
around the mobile station; 

detects respective reception levels of the perch channels for the near base 

stations; 

calculates respective path losses between the mobile station and respective 
near base stations on the basis of the respective reception levels and the respective 
perch channel transmission power levels within the broadcast information; 

calculates respective necessary uplink transmission power levels between the 
mobile station and respective near base stations on the basis of the calculated 
respective path losses, the respective uplink interference levels within the broadcast 
information, and required signal-to-interference ratios involved in reception by the 
near base stations; 

selects a radio zone in which the necessary uplink transmission power level is 
minimum among the respective necessary uplink transmission power levels, the base 
station of the selected radio zone being ready for communication with the mobile 
station or being able to commence communication with the mobile station after 
handover; and 
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controls an uplink transmission power in the selected radio zone based on the 
necessary uplink transmission power level of the selected radio zone. 

Additionally, the present invention provides a base station comprising means 
for transmitting broadcast information indicating a perch channel transmission power 
5 level and an uplink interference level via a perch channel. 

In addition, the present invention provides a mobile station characterized in 

that it 

receives broadcast information from near base stations around the mobile 
station via respective perch channels, the broadcast information from each of the near 
10 base stations indicating a perch channel transmission power level and an uplink 
interference level; 

detects respective reception levels of the perch channels for the near base 

stations; 

calculates respective path losses between the mobile station and respective 
15 near base stations on the basis of the respective reception levels and the respective 
perch channel transmission power levels within the broadcast information; 

calculates respective necessary uplink transmission power levels between the 
mobile station and respective near base stations on the basis of the calculated 
respective path losses, the respective uplink interference levels within the broadcast 
20 information, and required signal-to-interference ratios involved in reception by the 
near base stations; 

selects a radio zone of which the necessary uplink transmission power level is 
minimum among the respective necessary uplink transmission power levels, the base 
station of the selected radio zone being ready for communication with the mobile 
25 station or being able to commence communication with the mobile station after 
handover; and 

controls an uplink transmission power in the selected radio zone based on the 
necessary uplink transmission power level of the selected radio zone. 
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By virtue of the aspects of the invention as set forth, although perch channel 
transmission power levels for respective base stations are different from each other or 
one another, it is possible to optimize the uplink transmission power of the mobile 
station. 

5 The present invention provides a handover controlling method for additionally 

establishing a handover branch between a mobile station and a network, characterized 
in that a procedure for additional establishment of a branch is completed with a state 
transition to which the mobile station can commence communicating without waiting 
for a confirmation of synchronization for all branches. 

10 The present invention provides a handover controlling method further 

characterized in that the procedure for additional branch establishment is completed 
with confirmation of synchronization for one branch among the branches established 
for the mobile station. 

Additionally, the present invention provides a mobile station characterized in 

15 that if the mobile station has received a request from a network to establish a new 
additional branch between the network and the mobile station, the mobile station 
establishes the new branch and then starts diversity reception upon reception of a 
signal through the new branch. 

In addition, the present invention provides a base station characterized in 

20 that if the base station has received a request from a base station controller to 
establish a new additional branch between a mobile station and the base station for 
carrying out intra-cell diversity handover, the base station additionally establishes the 
new branch and then starts intra-cell diversity reception upon reception of a signal 
through the new branch. 

25 Additionally, the present invention provides a base station characterized in 

that if the base station has received a request from a base station controller to 
establish a new additional branch between a mobile station and the base station for 
carrying out inter-cell diversity handover, the base station establishes the new branch 
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and then starts sending the received signals to the base station controller that 
executes inter-cell diversity reception upon reception of a signal through the new 
branch. 

In addition, the present invention provides a base station controller 
5 characterized in that when the base station controller establishes a new additional 
branch between a mobile station and a network, the base station controller provides a 
request for establishing the new branch and then completes a procedure for additional 
establishment of the new branch without waiting for a confirmation of synchronization 
for all branches between the mobile station and the network. 
10 Furthermore, the present invention provides a base station controller farther 

characterized in that it provides the request for establishing the new branch being 
necessary for inter-cell diversity handover, and then starts inter-cell diversity 
reception .upon reception of signals through the branches being necessary for inter-cell 
diversity handover. 

15 By virtue of the aspects of the invention as set forth, since the procedure for 

additional establishment of the new branch is completed when the mobile station can 
communicate, the additional establishment procedure can be ended in a short time 
period. 

The present invention provides a radio mobile communication system wherein 
20 a plurality of channels can be established on a single carrier frequency by code division 
multiplex access, characterized in that the system comprises code-resource-assigning 
means for assigning at least a part of an assignable code resource to one of the 
channels in accordance with a transmission rate necessary for the corresponding 
channel, the part corresponding to a certain bandwidth corresponding to the 
25 transmission rate. 

Furthermore, the present invention provides a radio mobile communication 
system further comprising channel-assigning means for assigning one of the channels, 
to which a part of the assignable code resource is assigned, to a mobile station in 
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accordance with a transmission rate necessary for the mobile station. 

Additionally, the present invention provides a radio mobile communication 
system wherein a plurality of channels can be established on a single carrier frequency 
by code division multiplex access, characterized in that the system comprises a 
5 plurality of assignable code resources, each of code resources corresponding to a 
certain bandwidth and being independent of the other code resources; and reassigning 
means for reassigning a part of an assignable code resource to one of the channels to 
which a part of another assignable code resource is already assigned if there is not an 
unused code resource corresponding to a bandwidth suitable for a necessary 
10 transmission rate when assigning an unused assignable code resource to one of the 
fj channels in accordance with the necessary transmission rate. 

~p Additionally, the present invention provides a radio mobile communication 

i - § 

-f7 system further comprising unused-code-resource determining means for determining if 

: 

there is an unused code resource corresponding to a bandwidth suitable for a necessary 
15 transmission rate or not when assigning an unused assignable code resource to one of 
W the channels in accordance with the necessary transmission rate necessary. 

□ Furthermore, the present invention provides a radio mobile communication 

system according to claim 91, wherein at least one standard code resource 
corresponding to a predetermined bandwidth is preselected and the system comprises 
20 assignment-possibility-determining means for determining at predetermined moments 
if there is at least one unused standard code resource or not, the reassigning means 
reassigning a part of an assignable code resource to one of the channels to which a part 
of another assignable code resource is already assigned until an unused standard code 
resource is reserved if the determination result by the assignment-possibility- 
25 determining means has been negative. 

In addition, the present invention provides a radio base station for which a 
plurality of channels can be established on a single carrier frequency by code division 
multiplex access, characterized in that it comprises code-resource-assignment- 
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possibility-determining means for determining whether or not it is possible to assign 
at least a part of an assignable code resource to one of channels in accordance with a 
transmission rate necessary for the corresponding channel, the part corresponding to a 
certain bandwidth corresponding to the transmission rate. 
5 The present invention provides a base station controller further comprising 

channel-assigning means for assigning a channel, to which a part of assignable code 
resource is assigned, to a mobile station in accordance with a transmission rate 
necessary for the mobile station. 

Additionally, the present invention provides a method for controlling a radio 

10 mobile communication system wherein a plurality of channels can be established on a 
single carrier frequency by code division multiplex access, characterized in that the 
method comprises code-resource-assigning step for assigning at least a part of an 
assignable code resource to one of the channels in accordance with a transmission rate 
necessary for the corresponding channel, the part corresponding to a certain 

15 bandwidth corresponding to the transmission rate. 

In addition, the present invention provides a method for controlling a radio 
mobile communication system including a plurality of assignable code resources, each 
of code resources corresponding to a certain bandwidth and being independent of the 
other code resources, a plurality of channels being capable ofbeing established on a 

20 single carrier frequency by code division multiplex access, characterized in that in 
order to assign an unused assignable code resource to one of the channels in 
accordance with a necessary transmission rate, the method comprises the steps of 
determining whether or not there is an unused code resource having a code resource 
length in accordance with the necessary transmission rate; and reassigning a part of 

25 an assignable code resource to one of the channels to which a part of another 
assignable code resource is already assigned if the determination indicates that there 
is not an unused code resource having a bandwidth suitable for the necessary 
transmission rate. 
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Additionally, the present invention provides a method for controlling radio 
base station for which a plurality of channels can be established on a single carrier 
frequency by code division multiplex access, characterized in that it comprises a code- 
resource-assignment-possibility-determining step for determining whether or not it is 
possible to assign at least a part of an assignable code resource to one of channels in 
accordance with a transmission rate necessary for the corresponding channel, the part 
corresponding to a certain bandwidth corresponding to the transmission rate. 

In addition, the present invention provides a method for controlling a radio 
base station comprising a channel-assigning step for assigning a channel, to which a 
part of an assignable code resource is assigned to a mobile station in accordance with a 
transmission rate necessary for the mobile station. 

By virtue of the aspects of the invention as set forth, it is possible to minimize 
the number of reassignments or rearrangements of code resources for channels, and 
call generations do not involve the rearrangement of code resource. Therefore, it is 
possible to reduce connection time delay. 

BRIEF DESCRIPTION OF DRAWINGS 
Figure 1 is a block diagram showing the entire structure of a mobile 
communications system in accordance with W-CDMA of one embodiment of the 
present invention. 

Figure 2 is a block diagram showing a part of the system, particularly showing 
access interfaces in the system. 

Figure 3 is a diagram showing the functional network architecture of the 
system, in which functional entities are arranged in a communication control plane 
and a radio resource control plane. 

Figure 4 is a diagram showing the functional network architecture of the 
system, in which functional entities are arranged in a communication control plane 
and a radio resource control plane. 
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Figure 5 is a diagram showing the functional model of a part of the invented 
system for describing an origination for initial call. 

Figure 6 is a diagram showing the functional model of a part of the invented 
system for describing an origination for additional call. 
5 Figures 7 and 8 form an information flow diagram showing the origination for 

initial call. 

Figure 9 is an information flow diagram showing the origination for additional 

call. 

Figure 10 is a diagram showing the functional model of a part of the invented 
10 system for describing acceptance of initial incoming call. 

Figure 11 is a diagram showing the functional model of a part of the invented 
system for describing acceptance of additional incoming call. 

Figures 12 through 14 form an information flow diagram showing the 
acceptance of initial incoming call. 
15 Figures 15 and 16 form an information flow diagram showing the acceptance 

of additional incoming call. 

Figure 17 is a diagram showing the functional model of a part of the invented 
system for describing a disconnection instructed by a user. 

Figure 18 is an information flow diagram showing the disconnection 
20 instructed by a user. 

Figure 19 is a diagram showing the functional model of a part of the invented 
system for describing a disconnection instructed by the network. 

Figure 20 is an information flow diagram showing the disconnection 
instructed by the network. 
25 Figure 21 is a diagram showing the functional model of a part of the invented 

system for describing an abnormal release caused from a radio link failure detected by 
a mobile terminal. 

Figure 22 is an information flow diagram of the abnormal release caused from 
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the radio link failure detected by the mobile terminal. 

Figure 23 is a diagram showing the functional model of a part of the invented 
system for describing an abnormal release caused from a radio link failure detected by 
the network. 

Figure 24 is an information flow diagram of the abnormal release caused from 
the radio link failure detected by the network. 

Figure 25 is a diagram showing the functional model of a part of the invented 
system for describing a user disconnect. 

Figure 26 is an information flow diagram of the user disconnect. 

Figure 27 is a diagram showing the functional model of a part of the invented 
system for describing an SDCCH setup process. 

Figure 28 is an information flow diagram of the SDCCH setup process. 

Figure 29 is a diagram showing the functional model of a part of the invented 
system for describing a bearer setup for the radio resource selection. 

Figure 30 is an information flow diagram of the bearer setup, executed in the 
communication control plane, for the radio resource selection. 

Figure 31 is a diagram showing the functional model of a part of the invented 
system for describing a radio bearer release. 

Figure 32 is an information flow diagram of the radio bearer release. 

Figure 33 is a diagram showing the functional model of a part of the invented 
system for describing an SDCCH release. 

Figure 34 is an information flow diagram of the SDCCH release. 

Figure 35 is a flow chart showing handover processes in general. 

Figure 36 is an information flow diagram showing processes 1 and 2 described 

above. 

Figure 37 is an information flow diagram representing a sequence in which 
information flows are transported for starting non-soft handover execution, the 
sequence corresponding to process 1 in Figure 35. 
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Figure 38 is an information flow diagram representing a sequence in which 
information flows are transported for starting handover branch addition, the sequence 
corresponding to process 1 in Figure 35. 

Figure 39 is an information flow diagram representing a sequence in which 
5 information flows are transported for starting handover branch deletion, the sequence 
corresponding to process 1 in Figure 35. 

Figure 40 is a diagram showing the functional model of a part of the invented 
system for describing an inter-sector handover branch addition in a single cell. 

Figure 41 is an information flow diagram of the inter-sector handover branch 
10 addition in a single cell, executed in the communication control plane. 

Figure 42 is a diagram showing the functional model of a part of the invented 
system for describing an inter-cell handover branch addition. 

Figure 43 is an information flow diagram of the inter-cell handover branch 
addition, executed in the communication control plane. 
15 Figure 44 is a diagram showing the functional model of a part of the invented 

system for describing an inter-sector handover branch deletion in a single cell. 

Figure 45 is an information flow diagram of the inter-sector handover branch 
deletion in a single cell, executed in the communication control plane. 

Figure 46 is a diagram showing the functional model of a part of the invented 
20 system for describing an inter-cell handover branch deletion. 

Figure 47 is an information flow diagram of the inter-cell handover branch 
deletion, executed in the communication control plane. 

Figure 48 is a diagram showing the functional model of a part of the invented 
system for describing an intra-cell branch replacement handover. 
25 Figure 49 is an information flow diagram of the intra-cell branch replacement 

handover executed in the communication control plane. 

Figure 50 is a diagram showing the functional model of a part of the invented 
system for describing an inter-cell branch replacement handover. 
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Figure 51 is an information flow diagram of the inter-cell branch replacement 
handover executed in the communication control plane. 

Figure 52 is a diagram showing the functional model of a part of the invented 
system for describing an ACCH replacement procedure. 

Figures 53 and 54 cooperate to form an information flow diagram of the ACCH 
replacement procedure executed in the communication control plane. 

Figure 55 is a diagram showing the functional model of a part of the invented 
system for describing a code replacement. 

Figure 56 is an information flow diagram of the code replacement procedure 
executed in the communication control plane. 



Figure 57 is a diagram showing the functional model of a part of the invented 



flow diagram of the transmission power control executed in the communication control 
plane. 

Figure 59 is a diagram showing the functional model of a part of the invented 
system for describing a terminal location updating. 

Figures 60 and 61 form an information flow diagram of the terminal location 
updating. 

Figure 62 is a diagram showing the functional model of a part of the invented 
system for describing a user authentication. 

Figure 63 is an information flow diagram representing the user 
authentication procedure in the invented system. 

Figure 64 is a diagram showing functional entities in the invented system for 
describing an encipherment onset time notification. 

Figure 65 is an information flow diagram representing the encipherment 
onset time notification. 

Figure 66 is a diagram showing functional entities in the invented system for 
describing a TMUI assignment. 



system for describing a transmission power control. 



Figure 58 is an information 
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Figure 67 is an information flow diagram representing the TMUI assignment. 

Figure 68 is an information flow diagram representing a user ID retrieval. 

Figure 69 is a diagram representing the correlation between physical node 
configuration and functional entities in the invented system. 

Figure 70 is a diagram representing the signaling layer 2 protocol architecture 
over the radio interface. 

Figure 71 is a diagram representing a sample frame structure for the BSC 
function termination. 

Figure 72 is a diagram representing the format of a sequenced data PDU (SD 

PDU). 

Figure 73 is a diagram representing the format of a sequenced-data-with- 
status-request PDU (SD-with-POLL PDU). 

Figure 74 is a diagram representing the format of a POLL PDU. 

Figure 75 is a diagram representing the format of a STAT PDU. 

Figure 76 is a diagram representing the format of a USTAT PDU. 

Figure 77 is a diagram representing the format of a UD PDU and a MD PDU. 

Figure 78 is a diagram representing the format of a Begin PDU (BGN PDU). 

Figure 79 is a diagram representing the format of a BGAK PDU. 

Figure 80 is a diagram representing the format of a BGREJ PDU. 

Figure 81 is a diagram representing the format of an END PDU. 

Figure 82 is a diagram representing the format of an ENDAK PDU. 

Figure 83 is a diagram representing the format of an RS PDU. 

Figure 84 is a diagram representing the format of an RSAK PDU. 

Figure 85 is a diagram representing the format of an ER PDU. 

Figure 86 is a diagram representing the format of an ERAK PDU. 

Figure 87 is a diagram representing the frame format of an MDU and the 
frame format on the broadcasting channel (BCCH). 

Figure 88 is a diagram representing the frame format of an MDU and the 
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frame format on the perch channel (PCH). 

Figure 89 is a diagram representing the frame format of an MDU and the 
format of long and short frame on the random access channel (RACH). 

Figure 90 is a diagram representing the frame format of an MDU and the 
format of long frame on the forward access channel (FACH). 

Figure 91 is a diagram representing the frame format of an MDU and the 
format of short frame on the forward access channel (FACH). 

Figure 92 is a diagram representing the frame format of an MDU and the 
frame format on the stand alone dedicated control channel (SDCCH) 

Figure 93 is a diagram representing the frame format of an MDU and the 
frame format on the associated control channel (ACCH). 

Figure 94 is a diagram representing the frame format of an MDU and the 
frame format on the user packet channel (UPCH) 

Figure 95 is a conceptual diagram representing an example of the radio 
interface protocol architecture of layer 3 of the invented system. 

Figure 96 represents the basic format of RBC entity message of the invented 

system. 

Figure 97 represents structures of frames of an RBC entity message. 

Figure 98 is a diagram representing a common structure of CC 
(call/connection control) entity protocol messages. 

Figure 99 is a diagram representing a protocol discriminator of the CC entity 
protocol messages. 

Figure 100 is a diagram representing a call reference of the CC entity protocol 
messages. 

Figure 101 is a diagram representing a dummy call reference of the CC entity 
protocol messages. 

Figure 102 is a diagram representing the format of a message type identifier 
of each CC entity message. 
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Figures 103 and 104 are diagrams respectively representing the formats of 
variable length information elements according to FPLMTS. 

Figure 105 is a diagram representing the coding format of a broadband locking 
shift information element. 

5 

Figure 106 is a diagram representing the coding format of a broadband non- 
locking shift information element. 

Figures 107 through 111 form a diagram representing the coding format of an 
AAL parameter information element. 
10 Figure 112 is a diagram representing the format of an ATM traffic descriptor 

information element. 

Figure 113 is a diagram representing the format of a broadband bearer 
capability information element. 

Figure 114 is a diagram representing the format of a broadband high layer 
15 information element. 

Figures 115 and 116 form a diagram representing the format of a broadband 
low layer information element. 

Figure 117 is a diagram representing the format of a called party number 
information element. 

20 Figure 118 is a diagram representing the format of a called party sub-address 

information element. 

Figure 119 is a diagram representing the format of a calling party number 
information element. 

Figure 120 is a diagram representing the format of a calling party sub-address 
25 information element. 

Figure 121 is a diagram representing the format of a connection identifier 
information element. 

Figure 122 is a diagram representing the format of an end-to-end transit delay 
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information element. 

Figure 123 is a diagram representing the format of a QOS (quality of service) 
parameter information element. 

Figure 124 is a diagram representing the format of a broadband repeat 
indicator information element. 

Figure 125 is a diagram representing the format of a broadband sending 
complete information element. 

Figure 126 is a diagram representing the format of a transit network selection 
information element. 

Figure 127 is a diagram representing the format of a notification indicator 
information element. 

Figure 128 is a diagram representing the format of an OAM traffic descriptor 
information element. 

Figure 129 is a diagram representing the format of a narrow-band bearer 
capability information element. 

Figure 130 is a diagram representing the format of a narrow-band high layer 
compatibility information element. 

Figure 131 is a diagram representing the format of a narrow -band low layer 
compatibility information element. 

Figure 132 is a diagram representing the format of a progress indicator 
information element. 

Figure 133 is a diagram representing the format of a TMUI information 
element. 

Figure 134 is a diagram representing the format of a TMUI assignment source 

ID. 

Figure 135 is a diagram representing the format of an IMUI. 
Figure 136 is a diagram representing the format of an execution 
authentication type. 
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Figure 137 is a diagram representing the format of an authentication random 

pattern. 

Figure 138 is a diagram representing the format of an authentication 
ciphering pattern. 

Figure 139 is a diagram representing the format of an execution ciphering 

type. 

Figure 140 is a diagram representing the format of a TC information. 

Figure 141 is a diagram representing the format of a message type identifier 
of the RBC entity message. 

Figure 142 is a diagram representing the format of an information element 
identifier. 

Figure 143 is a diagram representing the format of a radio bearer setup 
message specific parameter. 

Figure 144 is a diagram representing the format of a radio bearer release 
message specific parameter. 

Figure 145 is a diagram representing the format of a radio bearer release 
complete message specific parameter. 

Figure 146 is a diagram representing the format of a handover command 
message specific parameter. 

Figure 147 is a diagram representing the format of a handover response 
message specific parameter. 

Figures 148 to 151 form a diagram representing the format of a radio bearer 
setup information. 

Figures 152 through 154 form a diagram representing the format of a DHO 
(diversity handover) branch addition information element. 

Figure 155 is a diagram representing the format of a DHO (diversity 
handover) branch deletion information element. 

Figure 156 is a diagram representing the format of an ACCH replacement 
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information element. 

Figures 157 through 159 form a diagram representing the format of a branch 
replacement information element. 

Figures 160 through 163 form a diagram representing the format of a user 
5 rate replacement information element. 

Figures 164 and 165 form a diagram representing the format of a code 
replacement information element. 

Figure 166 is a diagram representing the format of a message type identifier 
in RRC entity messages. 
10 Figure 167 is a diagram representing the format of a facility information 

element. 

Figure 168 and 169 form a diagram representing the format of an ROSE PDU. 

Figure 170 is a diagram representing the common format of parameters of 
number of visited candidate sectors, number of in-use visited sectors, number of 
15 candidate sectors to be added at DHO, number of sectors to be deleted at DHO, and 
candidate sectors for HHO. 

Figure 171 is a diagram representing the format of a BTS number parameter. 

Figure 172 is a diagram representing the format of a sector number 
parameter. 

20 Figure 173 is a diagram representing the format of a perch channel reception 

SIR parameter. 

Figure 174 is a diagram representing the format of a perch channel 
transmission power parameter. 

Figure 175 is a diagram representing the format of a long code phase 
25 difference parameter. 

Figure 176 is a diagram representing the format of a parameter of the number 
ofRBC IDs. 

Figure 177 is a diagram representing the format of a parameter of the RBC 
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ID. 

Figure 178 is a diagram representing the format of a parameter of the 
necessary SIR. 

Figure 179 is a diagram representing the format of a parameter of FER 
measurement. 

Figure 180 is a diagram representing the format of a TAC entity message. 

Figure 181 is a diagram representing the format of a protocol discriminator. 

Figure 182 is a diagram representing the format of a message type identifier. 

Figure 183 is a diagram representing the format of a terminal association 
setup message specific parameter. 

Figure 184 is a diagram representing the format of a paging response message 
specific parameter. 

Figure 185 is a diagram representing the format of a terminal association 
release message specific parameter. 

Figure 186 is a diagram representing the format of a cause information 

element. 

Figure 187 is a diagram representing the format of a mobile station type 
information element. 

Figure 188 is a diagram representing the format of a paged MS ID information 

element. 

Figure 189 is a diagram representing the format of a paging ID information 
element. - 

Figure 190 is a diagram representing the format of a TMUI information 

element. 

Figure 191 is a diagram representing the format of an extensional information 
element for TAC entity messages. 

Figure 192 is a diagram representing the format of a message type 
information element. 
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Figure 193 is a diagram representing the format of a length information 

element. 

Figure 194 is a diagram representing the format of a perch channel reception 
SIR information element. 
5 Figure 195 is a diagram representing the format of a short code number 

information element. 

Figure 196 is a diagram representing the format of a frame offset group 
information element. 

Figure 197 is a diagram representing the format of a slot offset group 
10 information element. 

Figure 198 is a diagram representing the format of a network number group 
information element. 

Figure 199 is a diagram representing the format of a network version 
information element. 

15 Figure 200 is a diagram representing the format of a mobile station common 

parameter version information element. 

Figure 201 is a diagram representing the format of a BTS number information 

element. 

Figure 202 is a diagram representing the format of a sector number 
20 information element. 

Figure 203 is a diagram representing the format of an information element 
indicating the number (N) of registration areas overlapped in one radio zone. 

Figure 204 is a diagram representing the format of an area number 
information element. 

25 Figure 205 is a diagram representing the format of an information element 

indicating the calibrated power level necessary for reception at the base station. 

Figure 206 is a diagram representing the format of an information element 
indicating the calibrated power level necessary for reception at the base station. 
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Figure 207 is a diagram representing the format of an information element 
indicating the number (M) of perch channel LC for determination of visited zone. 

Figure 208 is a diagram representing the format of an information element 
indicating the number (K) of frequency bands used by base station. 

Figure 209 is a diagram representing the format of a frequency band 
information element. 

Figure 210 is a diagram representing the format of a BCCH reception 
duration information element. 

Figure 211 is a diagram representing the format of an information element 
indicating the number of paged mobile stations. 

Figure 212 is a diagram representing the format of a paged MS ID information 
element. 

Figure 213 is a diagram representing the format of a paging ID information 

element. 

Figure 214 is a conceptual diagram representing the protocol architecture on a 
BTS-MCC interface. 

Figure 215 is a diagram representing the format of a BC entity message. 

Figure 216 is a diagram representing the format of a BSM entity message. 

Figure 217 is a diagram representing the format of the pattern of fundamental 
information elements in the BSM entity message. 

Figure 218 is a diagram representing the format of the pattern of each 
fundamental information element in the BC entity message. 

Figure 219 is a diagram representing the format of a protocol discriminator of 
a BC entity message. 

Figure 220 is a diagram representing the format of a message type identifier 
of a BC entity message. 

Figure 221 is a diagram representing the format of a parameter of link 
reference of a BC entity message. 
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Figure 222 is a diagram representing the format of an information element 
identifier of a BC entity message. 

Figure 223 is a diagram representing the format of a length of information 
element of a BC entity message. 

Figure 224 is a diagram representing the format of an AAL type parameter of 
a BC entity message. 

Figure 225 is a diagram representing the format of a link identifier of a BC 
entity message. 

Figure 226 is a diagram representing the format of a transmission quality 
parameter of a BC entity message. 

Figure 227 is a diagram representing the format of a sector number of a BC 
entity message. 

Figure 228 is a diagram representing the format of a bearer capability 
parameter of a BC entity message. 

Figure 229 is a diagram representing the format of a frequency selection 
information of a BC entity message. 

Figure 230 is a diagram representing the format of a frequency of a BC entity 
message. 

Figure 231 is a diagram representing the format of a frame offset group 
parameter of a BC entity message. 

Figure 232 is a diagram representing the format of a slot offset group of a BC 
entity message. 

Figure 233 is a diagram representing the format of a long code phase 
difference parameter of a BC entity message. 

Figure 234 is a diagram representing the format of a reverse long code number 
of a BC entity message. 

Figure 235 is a diagram representing the format of a reverse short code type 
parameter of a BC entity message. 



F0220/2551 



44 

Figure 236 is a diagram representing the format of a parameter of the number 
of reverse short codes of a BC entity message. 

Figure 237 is a diagram representing the format of a reverse short code 
number of a BC entity message. 

Figure 238 is a diagram representing the format of a forward short code type 
parameter of a BC entity message. 

Figure 239 is a diagram representing the format of a parameter of number of 
forward short codes of a BC entity message. 

Figure 240 is a diagram representing the format of an AAL type parameter for 
ACCH of a BC entity message. 

Figure 241 is a diagram representing the format of a link identifier for ACCH 
of a BC entity message. 

Figure 242 is a diagram representing the format of a transmission quality for 
ACCH of a BC entity message. 

Figure 243 is a diagram representing the format of a forward short code 
number of a BC entity message. 

Figure 244 is a diagram representing the format of a result parameter of a BC 
entity message. 

Figure 245 is a diagram representing the format of a cause parameter of a BC 
entity message. 

Figure 246 is a diagram representing the format of an initial transmission 
power parameter of a BC entity message. 

Figure 247 is a diagram representing the format of a location identity 
parameter of a BC entity message. 

Figure 248 is a diagram representing the format of a protocol discriminator of 
a BSM entity message. 

Figure 249 is a diagram representing the format of a message type identifier 
of a BSM entity message. 
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Figure 250 is a diagram representing the format of a PCHs calculation 
information of a BSM entity message. 

Figure 251 is a diagram representing the format of an area number of a BSM 
entity message. 

Figure 252 is a diagram representing the format of a paged MS ID of a BSM 
entity message. 

Figure 253 is a diagram representing the format of a paging ID of a BSM 
entity message. 

Figure 254 represents an SDL diagram for base station management. 

Figure 255 represents an SDL diagram for bearer control in the SDCCH 
executed in the BSC function of the network. 

Figure 256 represents an SDL diagram for bearer control in the TCH/ACCH 
executed in the BSC function of the network. 

Figure 257 represents an SDL diagram for bearer control in the SDCCH 
executed in the BTS. 

Figure 258 represents an SDL diagram for bearer control in the TCH/ACCH 
executed in the BTS. 

Figure 259 is a diagram showing radio zones and a travelling mobile station in 
the invented system for describing an exemplified handover process. 

Figure 260 is a block diagram showing an example of mobile communications 
system wherein a mobile station communicates through a plurality of calls. 

Figure 261 is a block diagram showing the invented mobile communications 
system wherein a mobile station communicates through a plurality of calls and 
capable of replacing an associated control channel. 

Figure 262 is a sequential diagram representing the ACCH replacement 
procedure carried out by the invented system. 

Figure 263 is a diagram showing the OSI reference model. 

Figure 264 is a diagram representing a sequential operation by the network 
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and a mobile station MS in the invented system, which starts after a call attempt 
comes in the network. 

Figure 265 is a table indicating the glossary of the abbreviations used in the 
present specification. 

5 Figure 266 is a table representing the features of services provided by the 

invented system. 

Figure 267 is a table representing the features of the voice bearer service at 8 
kbps provided by the invented system. 

Figure 268 is a table representing the features of the unrestricted bearer 
10 service at 64 kbps provided by the invented system. 

Figure 269 is a table representing the features of the multiple-rate 
unrestricted bearer service provided by the invented system. 

Figure 270 is a table representing the correlation between FE numbers and 
functional entities in the system. 
15 Figure 271 is a table representing the correlation between the relationship 

designations and the related functional entities. 

Figure 272 is a table representing the detail of a TA SETUP request 
indication. 

Figure 273 is a table representing the detail of another TA SETUP request 
20 indication. 

Figure 274 is a table representing the detail of a TA SETUP PERMISSION 
request indication. 

Figure 275 is a table representing the detail of a REVERSE LONG CODE 
RETRIEVAL request indication used to retrieve the reverse long code. 
25 Figure 276 is a table representing the detail of another REVERSE LONG 

CODE RETRIEVAL request indication used to retrieve the reverse long code. 

Figure 277 is a table representing the detail of a REVERSE LONG CODE 
RETRIEVAL response confirmation used to retrieve the reverse long code. 
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Figure 278 is a table representing the detail of a TERMINAL STATUS 
UPDATE request indication used to update the terminal status. 

Figure 279 is a table representing the detail of a TERMINAL STATUS 
UPDATE response confirmation. 

Figure 280 is a table representing the detail of an ADD-ROUTING 
INFORMATION request indication sent to an LRDF to add the routing address to the 
subscriber's profile. 

Figure 281 is a table representing the detail of an ADD-ROUTING 
INFORMATION response confirmation. 

Figure 282 is a table representing the detail of a TA SETUP PERMISSION 
response confirmation issued by the LRCF to inform the TACF that the mobile 
terminal access to the network is authorized. 

Figure 283 is a table representing the detail of a REVERSE LONG CODE 
RETRIEVAL response confirmation used to retrieve the reverse long code. 

Figure 284 is a table representing the detail of a TA SETUP response 
confirmation used to notify that the terminal access has been established. 

Figure 285 is a table representing the detail of another TA SETUP response 
confirmation used to confirm that the setup of terminal access and the connection 
between a CCAF and TACAF have been completed. 

Figure 286 is a table representing the detail of a SETUP request indication 
used to request the establishment of a connection. 

Figure 287 is a table representing the detail of a TACF INSTANCE ID 
INDICATION request indication used to retrieve the reverse long code. 

Figure 288 is a table representing the detail of a CELL CONDITION 
MEASUREMENT request indication. 

Figure 289 is a table representing the detail of a CELL CONDITION 
MEASUREMENT response confirmation that provides the result of the cell selection 
information measurement requested by the CELL CONDITION MEASUREMENT 
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request indication. 

Figure 290 is a table representing the detail of a CELL CONDITION REPORT 
request indication. 

Figure 291 is a table representing the detail of a CALL SETUP PERMISSION 
request indication issued by an SSF to request the authorization of the calling user. 

Figure 292 is a table representing the detail of a USER PROFILE 
RETRIEVAL request indication used to request the user profile to be retrieved. 

Figure 293 is a table representing the detail of a USER PROFILE 
RETRIEVAL response confirmation. 

Figure 294 is a table representing the detail of a CALL SETUP PERMISSION 
response confirmation issued by the LRCF to inform the calling user is authorized. 

Figure 295 is a table representing the detail of a SETUP request indication 
used to request the establishment of a connection. 

Figure 296 is a table representing the detail of a PROCEEDING request 
indication. 

Figure 297 is a table representing the detail of a MEASUREMENT 
CONDITION NOTIFICATION request indication used by the network to indicate 
conditions, which the mobile terminal measures, and to report the cell selection 
information. 

Figure 298 is a table representing the detail of another MEASUREMENT 
CONDITION NOTIFICATION request indication used by the network to indicate 
conditions, which the mobile terminal measures, and to report cell selecting 
information. 

Figure 299 is a table representing the detail of a REPORT request indication 
used to report status and/or other types of information (e.g. alerting, suspended, hold, 
and resume) transported within the network. 

Figure 300 is a table representing the detail of another REPORT request 
indication used to report status and/or other types of information (e.g. alerting, 
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suspended, hold, and resume) transported within the network. 

Figure 301 is a table representing the detail of a SETUP response 
confirmation used to confirm that the connection has been established. 

Figure 302 is a table representing the detail of another SETUP response 
confirmation used to confirm that the connection has been established. 

Figure 303 is a table representing the detail of a SETUP request indication 
used to report the establishment of a connection. 

Figure 304 is a table representing the detail of a ROUTING INFORMATION 
QUERY request indication used to inquire the routing information. 

Figure 305 is a table representing the detail of a TERMINAL ID RETRIEVAL 
request indication used to request the user profile to be retrieved. 

Figure 306 is a table representing the detail of a TERMINAL ID RETRIEVAL 
response confirmation that is the response to the TERMINAL ID RETRIEVAL request 
indication. 

Figure 307 is a table representing the detail of a TERMINAL STATUS 
QUERY request indication used to inquire the terminal status (e.g. if terminal access 
is active or not). 

Figure 308 is a table representing the detail of a TERMINAL STATUS 
QUERY response confirmation that is the response to the TERMINAL STATUS 
QUERY request indication. 

Figure 309 is a table representing the detail of a TERMINAL STATUS 
UPDATE request indication used to update the terminal status. 

Figure 310 is a table representing the detail of a TERMINAL STATUS 
UPDATE response confirmation that is the response to the TERMINAL STATUS 
UPDATE request indication. 

Figure 311 is a table representing the detail of a PAGING AREA QUERY 
request indication used to inquire the paging area where TACF resides when it is 
observed that the terminal access is not active. Figure 312 is a table representing 
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the detail of a PAGING AREA QUERY response confirmation is the response to the 
PAGING AREA QUERY request indication. 

Figure 313 is a table representing the detail of a PAGE request indication 
used to trigger a TACF of paging. 

Figure 314 is a table representing the detail of a PAGING request indication 
used to page a mobile terminal for determining its position in the network and for the 
routing for a call. 

Figure 315 is a table representing the detail of a PAGING response 
confirmation used to respond to the request indication. 

Figure 316 is a table representing the detail of a PAGE response confirmation 
that is the response to the request indication and notifies a LRCF of the paging result. 

, Figure 317 is a table representing the detail of a REVERSE LONG CODE 
RETRIEVAL request indication used to retrieve the reverse long code. 

Figure 318 is a table representing the detail of another REVERSE LONG 
CODE RETRIEVAL request indication used to retrieve the reverse long code. 

Figure 319 is a table representing the detail of a REVERSE LONG CODE 
RETRIEVAL response confirmation used to retrieve the reverse long code. 

Figure 320 is a table representing the detail of a CELL CONDITION 
MEASUREMENT request indication used by the MRRC to trigger the measurement of 
cell selecting information. 

Figure 321 is a table representing the detail of a CELL CONDITION 
MEASUREMENT response confirmation provides the result of the cell selection 
information measurement requested by the CELL CONDITION MEASUREMENT 
request indication. 

Figure 322 is a table representing the detail of a CELL CONDITION REPORT 
request indication used by the mobile terminal to report the cell selection information. 

Figure 323 is a table representing the detail of an ADD-ROUTING 
INFORMATION request indication sent to the LRDFp to add the routing information 
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to the subscriber's profile. 

Figure 324 is a table representing the detail of an ADD-ROUTING 
INFORMATION response confirmation that is the response to the ADD-ROUTING 
INFORMATION request indication. 

Figure 325 is a table representing the detail of a PAGE AUTHORIZED 
request indication at relationship rg used to notify the TACF of the result of the 
terminal authentication. 

Figure 326 is a table representing the detail of a REVERSE LONG CODE 
RETRIEVAL response confirmation used to retrieve the reverse long code. 

Figure 327 is a table representing the detail of a ROUTING INFORMATION 
QUERY response confirmation that is the response to the request indication. 

Figure 328 is a table representing the detail of a SETUP request indication 
used to request the establishment of a connection. 

Figure 329 is a table representing the detail of a TERMINATION ATTEMPT 
request indication used to request the user's profile which may be needed to proceed 
the call process. 

Figure 330 is a table representing the detail of a USER PROFILE 
RETRIEVAL request indication used to retrieve the called user's profile from the 
LRDE 

Figure 331 is a table representing the detail of a USER PROFILE 
RETRIEVAL response confirmation that is the response to the request indication from 
the LRCF. 

Figure 332 is a table representing the detail of a TERMINATION ATTEMPT 
response confirmation that is the response to the request indication from the SSF. 

Figure 333 is a table representing the detail of a SETUP request indication 
used to request the establishment of a connection. 

Figure 334 is a table representing the detail of a PROCEEDING request 
indication optionally reports that the received connection setup is valid and 
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authenticated and that further routing and progressing of the call is proceeding. 

Figure 335 is a table representing the detail of a MEASUREMENT 
CONDITION NOTIFICATION request indication used by the network to indicate 
conditions, which the mobile terminal measures, and to report the cell selection 
5 information. 

Figure 336 is a table representing the detail of a REPORT request indication 
used to report status and/or other types of information transported in the network. 

Figure 337 is a table representing the detail of a SETUP response 
confirmation used to confirm that the connection has been established. 
10 Figure 338 is a table representing the detail of a CONNECTED request 

indication used to acknowledge that a previously sent SETUP response confirmation 
has been received and accepted. 

Figure 339 is a table representing the detail of a RELEASE request indication 
used to release the resources associated with the call connection, such as call ID and 
15 channels. 

Figure 340 is a table representing the detail of a RELEASE response 
confirmation used to indicate that all resources pervasively associated with the 
connection have been released. 

Figure 341 is a table representing the detail of a TA RELEASE request 
20 indication used to inform an SCF that the attempt of call release has been detected. 

Figure 342 is a table representing the detail of a TERMINAL-STATUS- 
MAKE-IDLE request indication used to idle the terminal call status. 

Figure 343 is a table representing the detail of a TERMINAL-STATUS - 
MAKE-IDLE response confirmation that is the response to the TERMINAL-STATUS - 
25 MAKE-IDLE request indication. 

Figure 344 is a table representing the detail of a TA RELEASE response 
confirmation used for the confirmation to the TA RELEASE request indication. 

Figure 345 is a table representing the detail of a RELEASE request indication 
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used to release the resources associated with the call connection such as the call 
reference and channels. 

Figure 346 is a table representing the detail of a RELEASE response 
confirmation used to indicate that all resources previously associated with the 
connection have been released. 

Figure 347 is a table representing the detail of a TA RELEASE request 
indication issued by the TACF to inform the LRCF that the attempt of call release has 
been detected. 

Figure 348 is a table representing the detail of a TERMINAL-STATUS - 
MAKE-IDLE request indication used to idle the terminal call status. 

Figure 349 is a table representing the detail of a TERMINAL-STATUS - 
MAKE-IDLE response confirmation that is the response to the TERMINAL-STATUS - 
MAKE-IDLE request indication. 

Figure 350 is a table representing the detail of a TA RELEASE response 
confirmation used for a confirmation of the TERMINAL-STATUS-MAKE-IDLE 
request indication. 

Figure 351 is a table representing the detail of a RADIO LINK FAILURE 
request indication used to notify a radio link failure detected by a BCAF or BCFr. 

Figure 352 is a table representing the detail of a RELEASE NOTIFICATION 
request indication used to indicate that a connection between the network and the 
terminal has been released. 

Figure 353 is a table representing the detail of a RADIO LINK FAILURE 
request indication used to notify that the link failure has been detected. 

Figure 354 is a table representing the detail of another RADIO LINK 
FAILURE request indication used to notify that the link failure has been detected. 

Figure 355 is a table representing the detail of a RADIO LINK FAILURE 
response confirmation that is a response confirmation of the RADIO LINK FAILURE 
request indication. 
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Figure 356 is a table representing the detail of a RADIO BEARER RELEASE 
request indication used to request to release radio bearers. 

Figure 357 is a table representing the detail of a BEARER RELEASE request 
indication issued by the TACF to the BCF to release the radio bearer. 

Figure 358 is a table representing the detail of a BEARER RELEASE 
response confirmation that is a response confirmation of the BEARER RELEASE 
request indication. 

Figure 359 is a table representing the detail of another BEARER RELEASE 
request indication sent by an anchor TACF to request a serving TACF to release the 
bearer involved in the call that should be released. 

Figure 3G0 is a table representing the detail of another BEARER RELEASE 
request indication issued by the TACF to BCF to release the radio bearer. 

Figure 361 is a table representing the detail of another BEARER RELEASE 
response confirmation that is a response confirmation of the BEARER RELEASE 
request indication. 

Figure 362 is a table representing the detail of a BEARER- AND-RADIO- 
BEARER RELEASE request indication issued by the TACF to release the bearer-and- 
radio-bearer. 

Figure 363 is a table representing the detail of a BEARER-AND-RADIO- 
BEARER RELEASE response confirmation used for a confirmation of the release of 
the bearer-and-radio-bearer requested by the BEARER-AND-RADIO-BEARER 
RELEASE request indication. 

Figure 364 is a table representing the detail of another BEARER RELEASE 
response confirmation that is a confirmation response to inform the TACF that the 
previous request to release the radio bearer has been completed. 

Figure 365 is a table representing the detail of a TA RELEASE request 
indication issued by the TACF to inform the LRCF that the attempt of releasing call 
has detected. 
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Figure 366 is a table representing the detail of a TERMINAL-STATUS- 
MAKE-IDLE request indication used to request to update the user profile. 

Figure 367 is a table representing the detail of a TERMINAL-STATUS - 
MAKE-IDLE response confirmation that is a response to the TERMI N AL-STATUS - 
MAKE-IDLE request indication. 

Figure 368 is a table representing the detail of a TA RELEASE response 
confirmation used for a response confirmation of the TA RELEASE request indication. 

Figure 369 is a table representing the detail of a RADIO LINK FAILURE 
request indication used to notify that a link failure has been detected and reported by 
either BCFr or BCFa. 

Figure 370 is a table representing the detail of another RADIO LINK 
FAILURE request indication used to notify that the link failure has been detected. 

Figure 371 is a table representing the detail of a RADIO LINK FAILURE 
response confirmation that is a confirmation response to the RADIO LINK FAILURE 
request indication. 

Figure 372 is a table representing the detail of a RADIO BEARER RELEASE 
request indication used to request to release the radio bearer. 

Figure 373 is a table representing the detail of a RELEASE NOTIFICATION 
request indication used to indicate that the connection between the network and the 
terminal has been released. 

Figure 374 is a table representing the detail of a RADIO BEARER RELEASE 
response confirmation that is a response confirmation of the RADIO BEARER 
RELEASE request indication. 

Figure 375 is a table representing the detail of a BEARER RELEASE request 
indication issued by the TACF to BCF to release the radio bearer. 

Figure 376 is a table representing the detail of a BEARER RELEASE 
response confirmation that is a response confirmation of the BEARER RELEASE 
request indication. 
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Figure 377 is a table representing the detail of another BEARER RELEASE 
request indication sent by the anchor TACF to request the serving TACF to release the 
radio bearer involved in the call that should be released. 

Figure 378 is a table representing the detail of another BEARER RELEASE 
request indication issued by the TACF to BCF to release the radio bearer. 

Figure 379 is a table representing the detail of a BEARER RELEASE 
response confirmation that is a response confirmation of the BEARER RELEASE 
request indication. 

Figure 380 is a table representing the detail of a BEARER-AND-RADIO- 
BEARER RELEASE request indication issued by the TACF to release the bearer and 
radio bearer. 

Figure 381 is a table representing the detail of a BEARER-AND-RADIO- 
BEARER RELEASE response confirmation used for a confirmation of the release of 
the bearer and radio bearer requested by the BEARER-AND-RADIO-BEARER 
RELEASE request indication. 

Figure 382 is a table representing the detail of another BEARER RELEASE 
response confirmation that is a confirmation response for informing the TACF that the 
previous request to release the radio bearer has been completed. 

Figure 383 is a table representing the detail of a RADIO BEARER RELEASE 
request indication issued to request to release the radio bearer. 

Figure 384 is a table representing the detail of another RADIO BEARER 
RELEASE response confirmation used to confirm the release of radio bearer requested 
by the RADIO BEARER RELEASE request indication. 

Figure 385 is a table representing the detail of a TA RELEASE request 
indication issued by the TACF to inform the LRCF that the attempt of call release has 
been detected. 

Figure 386 is a table representing the detail of a TERMINAL-STATUS- 
MAKE-IDLE request indication used to request to update the user profile. 
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Figure 387 is a table representing the detail of a TERMINAL-STATUS - 
MAKE-IDLE response confirmation that is a response to the TERMINAL-STATUS - 
MAKE-IDLE request indication. 

Figure 388 is a table representing the detail of another TA RELEASE response 
5 confirmation is used for confirmation to the TA RELEASE request indication. 

Figure 389 is a table representing the detail of a CALL DISCONNECT 
request indication used to notify the LRCF that a "user disconnect" has been detected. 

Figure 390 is a table representing the detail of a USER-PROFILE-UPDATE 
request indication used to request to update the user profile. 
10 Figure 391 is a table representing the detail of a USER-PROFILE-UPDATE 

response confirmation that is a response to the USER-PROFILE-UPDATE response 
confirmation. 

Figure 392 is a table representing the detail of a CALL DISCONNECT 
response confirmation that is a response to the request made by the CALL 
15 DISCONNECT request indication. 

Figure 393 is a table representing the detail of a SIGNALING CHANNEL 
SETUP REQUEST request indication used by the MCF and TACF to request the 
network to setup the signaling channels. 

Figure 394 is a table representing the detail of a SIGNALING CHANNEL 
20 SETUP request indication used by an SCMAF to request to the network to allocate the 
signaling channels. 

Figure 395 is a table representing the detail of a SIGNALING CHANNEL 
SETUP response confirmation used by the SCMF to allocate the radio resources to the 
signaling channels. 

25 Figure 396 is a table representing the detail of a SIGNALING CHANNEL 

SETUP REQUESTED request indication used to indicate the reception of the 
signaling channel setup request (initial access detection) from the mobile terminal and 
to request the network to setup the corresponding signaling channels in the network. 
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Figure 397 is a table representing the detail of a SIGNALING CONNECTION 
SETUP request indication used by the TACF and SACF to setup the signaling 
connection among them and the SCMR 

Figure 398 is a table representing the detail of a SIGNALING CONNECTION 
5 SETUP response confirmation used to report the establishment of the signaling 
channels including the physical radio channel and the intra-network channel. 

Figure 399 is a table representing the detail of a SIGNALING CHANNEL 
SETUP REQUEST response confirmation used by the SCMAF to report the setup of 
the signaling channels to the network. 
10 Figure 400 is a table representing the detail of a BEARER SETUP request 

indication used to request the establishment of the access bearer from the CCF to 
TACF. 

Figure 401 is a table representing the detail of a CHANNEL SELECTION 
response confirmation used to report reserved radio resources to the TACF, which 
15 requested the reservation. 

Figure 402 is a table representing the detail of a BEARER SETUP request 
indication sent from the TACF to BCF to request the establishment of the access 
bearer. 

Figure 403 is a table representing the detail of a BEARER SETUP response 
20 confirmation sent to confirm the establishment of the access bearer and to indicate the 
bearer ID of the bearer between the BCF and BCF. 

Figure 404 is a table representing the detail of another BEARER SETUP 
request indication used to request the establishment of the access bearer from the 
TACFa to TACFv. 

25 Figure 405 is a table representing the detail of another BEARER SETUP 

request indication sent from the TACF to BCF to request the establishment of the 
access bearer. 

Figure 406 is a table representing the detail of another BEARER SETUP 
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response confirmation sent from the BCF to TACF to request the establishment of the 
access bearer. 

Figure 407 is a table representing the detail of a BEARER-AND-RADIO- 
BEARER SETUP request indication sent from the TACF to BCFr to request the 
establishment of the radio bearer and the bearer between the BCF and BCFr. 

Figure 408 is a table representing the detail of a RADIO BEARER SETUP 
PROCEEDING request indication used by the BCFr to report that the instructed radio 
bearer setup is valid and the establishment of the radio bearer is proceeding. 

Figure 409 is a table representing the detail of a RADIO BEARER SETUP 
REQUEST request indication issued by the TACF, which controls a new access bearer, 
to the TACF, which has the signaling connection, to request to newly assign a radio 
bearer to the mobile terminal. 

Figure 410 is a table representing the detail of a RADIO BEARER SETUP 
request indication sent from the TACF to TACAF to request the establishment of the 
radio bearer. 

Figure 411 is a table representing the detail of another RADIO BEARER 
SETUP request indication sent from the TACAF to BCAF to request the establishment 
of the radio bearer. 

Figure 412 is a table representing the detail of a RADIO BEARER SETUP 
response confirmation sent from the BCAF to TACAF to confirm that the 
establishment of radio bearer has been completed. 

Figure 413 is a table representing the detail of a BEARER- AND -RADIO- 
BEARER SETUP response confirmation sent to confirm that the establishment of 
radio bearer and bearer between the BCF and BCFr have been completed. 

Figure 414 is a table representing the detail of a BEARER SETUP response 
confirmation used to confirm that the establishment of access bearer has been 
completed. 

Figure 415 is a table representing the detail of another BEARER SETUP 
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response confirmation used to confirm that the establishment of access bearer has 
been completed. 

Figure 416 is a table representing the detail of a BEARER RELEASE request 
indication sent by an anchor CCF to notify an anchor TACF that the attempt or event 
of call release has been detected and that the bearer involved in the call is being 
released. 

Figure 417 is a table representing the detail of a RADIO BEARER RELEASE 
request indication used by the TACFa to request to release the radio bearer. 

Figure 418 is a table representing the detail of a RADIO BEARER RELEASE 
response confirmation that is a response confirmation of the RADIO BEARER 
RELEASE request indication. 

Figure 419 is a table representing the detail of a BEARER RELEASE request 
indication issued by the TACF to BCF to release the radio bearer. 

Figure 420 is a table representing the detail of a BEARER RELEASE 
response confirmation that is a response confirmation of the BEARER RELEASE 
request indication. 

Figure 421 is a table representing the detail of another BEARER RELEASE 
request indication sent by the TACFa to request the TACFv to release the bearer 
involved in the call is being released. 

Figure 422 is a table representing the detail of another BEARER RELEASE 
request indication issued by the TACF to BCF to release the radio bearer. 

Figure 423 is a table representing the detail of a BEARER RELEASE 
response confirmation that is a response confirmation of the BEARER RELEASE 
request indication. 

Figure 424 is a table representing the detail of a BEARER- AND-RADIO- 
BEARER RELEASE request indication issued by the TACF to release the bearer and 
radio bearer. 

Figure 425 is a table representing the detail of a BEARER-AND-RADIO- 
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BEARER RELEASE response confirmation used for a confirmation of the release of 
the bearer and radio bearer requested by the BEARER-AND-RADIO-BEARER 
RELEASE request indication. 

Figure 426 is a table representing the detail of another BEARER RELEASE 
5 response confirmation that is a confirmation of the BEARER RELEASE request 
indication. 

Figure 427 is a table representing the detail of another BEARER RELEASE 
response confirmation that is a response confirmation to inform the CCF that the 
previous request to release the radio bearer has been completed. 
10 Figure 428 is a table representing the detail of another RADIO BEARER 

RELEASE request indication issued by the TACAF to request the radio bearer release. 

Figure 429 is a table representing the detail of another RADIO BEARER 
RELEASE request indication used by the BOCA to confirm the radio bearer release 
requested by the RADIO BEARER RELEASE request indication. 
15 Figure 430 is a table representing the detail of a SIGNALING CHANNEL 

RELEASE REQUEST request indication used by the MCF and TACF to request the 
release of a signaling channel. 

Figure 431 is a table representing the detail of a SIGNALING CONNECTION 
RELEASE request indication used by the TACF and SACF to request the release of the 
20 signaling channel (in both of the network and the radio resources). 

Figure 432 is a table representing the detail of a SIGNALING CONNECTION 
RELEASE response confirmation used to report the release of the signaling channel. 

Figure 433 is a table representing the detail of a BEARER SETUP request 
indication sent from the TACFa to TACFv to request the setup of an access bearer. 
25 Figure 434 is a table representing the detail of an INTRA-BCFr HANDOVER 

BRANCH ADDITION request indication. 

Figure 435 is a table representing the detail of an INTRA-BCFr HANDOVER 
BRANCH ADDITION response confirmation that is a response to the INTRA-BCFr 
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HANDOVER BRANCH ADDITION request indication and is sent from the BCFr to 
TACF to indicate the completion of setup of the physical radio channel(s). 

Figure 436 is a table representing the detail of a RADIO BEARER SETUP 
REQUEST request indication sent from the visited TACF, which controls the newly 
assigned radio bearer, to TACFa to request to setup the radio bearer between the 
mobile terminal and BCFr controlled by the visited TACF. 

Figure 437 is a table representing the detail of a HANDOVER BRANCH 
ADDITION request indication sent from the TACF to TACAF to notify of the intra- 
BCFr handover branch addition, and requesting to add a new physical radio channel to 
an existing physical radio channel. 

Figure 438 is a table representing the detail of a RADIO BEARER SETUP 
request indication sent from the TACAF to BCAF to request to setup a radio bearer. 

Figure 439 is a table representing the detail of a RADIO BEARER SETUP 
response confirmation that is a response to the RADIO BEARER SETUP request 
indication sent from the BCAF to TACAF to indicate the completion of the radio bearer 
setup. 

Figure 440 is a table representing the detail of a HANDOVER CONNECTION 
SETUP request indication notifying of a handover initiation and to request to setup an 
access bearer. 

Figure 441 is a table representing the detail of a HANDOVER CONNECTION 
SETUP response confirmation sent from the BCF to TACF to confirm the HANDOVER 
CONNECTION SETUP request indication. 

Figure 442 is a table representing the detail of a BEARER SETUP request 
indication sent from the TACFa to TACFv to setup an access bearer. 

Figure 443 is a table representing the detail of another BEARER SETUP 
request indication sent from the TACF to BCF to request the bearer setup. 

Figure 444 is a table representing the detail of a BEARER SETUP response 
confirmation sent from the BCF to TACF to confirm the BEARER SETUP request 
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indication. 

Figure 445 is a table representing the detail of a BEARER-AND-RADIO- 
BEARER SETUP request indication. 

Figure 446 is a table representing the detail of a BEARER-AND-RADIO- 
BEARER SETUP response confirmation sent from the BCFr to TACF to indicate the 
completion of setting up of the radio bearer and bearer between the BCFr and BCF. 

Figure 447 is a table representing the detail of a RADIO BEARER SETUP 
REQUEST request indication sent from the visited TACF, which controls the newly 
assigned radio bearer, to the TACFa to request to setup the radio bearer between the 
mobile terminal and BCFr. 

Figure 448 is a table representing the detail of a HANDOVER BRANCH 
ADDITION request indication notifying of the handover branch addition request. 

Figure 449 is a table representing the detail of a RADIO BEARER SETUP 
request indication sent from the TACAF to BCAF. 

Figure 450 is a table representing the detail of a RADIO BEARER SETUP 
response confirmation sent from the BCAF to TACAF to indicate the completion of the 
radio bearer setup. 

Figure 451 is a table representing the detail of a BEARER SETUP response 
confirmation sent from the TACFa to TACFv to confirm the establishment of the access 
bearer. 

Figure 452 is a table representing the detail of a HANDOVER BRANCH 
DELETION request indication. 

Figure 453 is a table representing the detail of a HANDOVER BRANCH 
DELETION response confirmation sent from the TACAF to TACF to confirm the 
HANDOVER BRANCH DELETION request indication. 

Figure 454 is a table representing the detail of a BEARER RELEASE request 
indication sent from the TACFa to TACFv to release the access bearer. 

Figure 455 is a table representing the detail of an INTRA-BCFr HANDOVER 
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BRANCH DELETION request indication sent from the TACF to BCFr to request the 
release of the physical radio channel(s). 

Figure 456 is a table representing the detail of an INTRA-BCFr HANDOVER 
BRANCH DELETION response confirmation sent from the BCFr to TACF to indicate 
5 the release of the physical radio channel(s). 

Figure 457 is a table representing the detail of a BEARER RELEASE 
response confirmation sent from the TACFv to TACFa to confirm the BEARER 
RELEASE request indication. 

Figure 458 is a table representing the detail of a HANDOVER BRANCH 
10 DELETION request indication sent from the TACF to TACAF. 

Figure 459 is a table representing the detail of a HANDOVER BRANCH 
DELETION response confirmation sent from the TACAF to TACF to confirm the 
HANDOVER BRANCH DELETION request indication. 

Figure 460 is a table representing the detail of a RADIO BEARER RELEASE 
15 request indication sent from the TACAF to BCAF to request the radio bearer release. 

Figure 461 is a table representing the detail of a RADIO BEARER RELEASE 
response confirmation sent from the BCFr to TACAF to indicate the completion of the 
radio bearer release. 

Figure 462 is a table representing the detail of a HANDOVER CONNECTION 
20 RELEASE request indication sent from the TACF to BCF to release the indicated 
bearer in the diversity handover state. 

Figure 463 is a table representing the detail of a HANDOVER CONNECTION 
RELEASE response confirmation sent from the BCF to TACF to confirm the 
HANDOVER CONNECTION RELEASE request indication. 
25 Figure 464 is a table representing the detail of a BEARER RELEASE request 

indication sent from the TACFa to TACFv to release the access bearer. 
Figure 465 is a table representing the detail of another BEARER RELEASE request 
indication sent from the TACF to BCF to request the bearer release. 
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Figure 466 is a table representing the detail of a BEARER RELEASE 
response confirmation sent from the BCF to TACF to confirm the BEARER RELEASE 
request indication. 

Figure 467 is a table representing the detail of a BE ARER- AND-RAD I O - 
BEARER RELEASE request indication sent from the TACF to BCFr to request the 
bearer between the BCF and BCFr and the radio bearer. 

Figure 468 is a table representing the detail of a BEARER-AND-RADIO- 
BEARER RELEASE response confirmation sent from the BCFr to TACF to indicate 
the completion of the release of the bearer and the radio bearer. 

Figure 469 is a table representing the detail of a BEARER RELEASE 
response confirmation sent from the TACFv to TACFa to confirm the BEARER 
RELEASE request indication. 

Figure 470 is a table representing the detail of a BEARER SETUP request 
indication sent from the TACFa to TACFv to setup an access bearer. 

Figure 471 is a table representing the detail of an INTRA-BCFr HANDOVER 
BRANCH REPLACEMENT response confirmation sent from the BCFr to TACF to 
indicate the completion of the setup of the physical radio channel(s). 

Figure 472 is a table representing the detail of an INTRA-BCFr HANDOVER 
BRANCH REPLACEMENT PROCEEDING request indication sent from the BCFr to 
TACF to indicate that the request of the handover branch replacement is accepted. 

Figure 473 is a table representing the detail of a RADIO BEARER SETUP 
REQUEST request indication sent from the visited TACF, which controls the newly 
assigned radio bearer, to the anchor TACFa to request to setup the radio bearer 
between the mobile terminal and BCFr controlled by the visited TACF. 

Figure 474 is a table representing the detail of a NON-SOFT HANDOVER 
EXECUTION request indication sent from the TACF to TACAF to notify of a non-soft 
handover execution request initiation. 

Figure 475 is a table representing the detail of a RADIO BEARER SETUP 
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request indication sent from the TACAF to BCAF to request to setup a radio bearer. 

Figure 476 is a table representing the detail of a RADIO BEARER SETUP 
response confirmation sent from the BCAF to TACAF to indicate the completion of the 
radio bearer setup. 

Figure 477 is a table representing the detail of a RADIO BEARER RELEASE 
request indication sent from the TACAF to BCAF to request the radio bearer release. 

Figure 478 is a table representing the detail of a RADIO BEARER RELEASE 
response confirmation sent from the BCAF to TACAF to indicate the completion of the 
radio bearer release. 

Figure 479 is a table representing the detail of a BEARER SETUP response 
confirmation sent from the TACFa to TACFv to confirm the establishment of the access 
bearer. 

Figure 480 is a table representing the detail of a HANDOVER CONNECTION 
SETUP request indication sent from the TACFa to BCFa to notify of a handover 
initiation. 

Figure 481 is a table representing the detail of a HANDOVER CONNECTION 
SETUP response confirmation sent from the BCF to TACF to confirm the HANDOVER 
CONNECTION SETUP request indication. 

Figure 482 is a table representing the detail of a BEARER SETUP request 
indication sent from the TACFa to TACFv to set up a new handover link. 

Figure 483 is a table representing the detail of another BEARER SETUP 
request indication sent from the TACF to BCF to request a new handover link in the 
network. 

Figure 484 is a table representing the detail of a BEARER SETUP response 
confirmation sent from the BCF to TACF to confirm a BEARER SETUP request 
indication. 

Figure 485 is a table representing the detail of a BEARER-AND-RADIO- 
BEARER SETUP request indication sent from the TACF to BCFr to request to set up a 
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bearer between the, BCF and BCFr and a radio bearer. 

Figure 486 is a table representing the detail of a RADIO BEARER SETUP 
PROCEEDING request indication sent from the BCFr to TACF to indicate that the 
request of the access radio link setup is accepted and that the BCFr starts setting up 
the access radio link. 

Figure 487 is a table representing the detail of a RADIO BEARER SETUP 
REQUEST request indication. 

Figure 488 is a table representing the detail of a NON-SOFT HANDOVER 
EXECUTION request indication sent from the TACF to TACAF to notify of a NON- 
SOFT HANDOVER EXECUTION request indication. 

Figure 489 is a table representing the detail of a RADIO BEARER SETUP 
request indication sent from the TACAF to BCAF to request to set up an access radio 
link. 

Figure 490 is a table representing the detail of a RADIO BEARER SETUP 
response confirmation sent from the BCAF to TACAF to indicate the completion of the. 
setup of the access radio link. 

Figure 491 is a table representing the detail of a RADIO BEARER RELEASE 
request indication sent from the TACAF to BCAF to request to release the access radio 
link. 

Figure 492 is a table representing the detail of a RADIO BEARER RELEASE 
response confirmation sent from the BCAF to TACAF to request to release the access 
radio link. 

Figure 493 is a table representing the detail of a BEARER-AND-RADIO- 
BEARER SETUP response confirmation sent from the BCFr to TACF to indicate the 
completion of the setup of the access radio link and the link between the BCFr and 
BCF. 

Figure 494 is a table representing the detail of a BEARER SETUP response 
confirmation sent from the TACFa to TACFv to confirm the establishment of the 
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handover link. 

Figure 495 is a table representing the detail of a HANDOVER CONNECTION 
RELEASE request indication sent from the TACF to BCFa to request to remove the 
indicated handover link. 

Figure 496 is a table representing the detail of a HANDOVER CONNECTION 
RELEASE response confirmation sent from the BCF to TACF to confirm the 
HANDOVER CONNECTION RELEASE request indication. 

Figure 497 is a table representing the detail of a BEARER RELEASE request 
indication sent from the TACFa to TACFv to request to release the handover link in 
the network. 

Figure 498 is a table representing the detail of another BEARER RELEASE 
request indication sent from the TACF to BCF to request to release the handover link 
in the network. 

Figure 499 is a table representing the detail of a BEARER RELEASE 
response confirmation sent from the BCF to TACF to confirm the BEARER RELEASE 
request indication. 

Figure 500 is a table representing the detail of a BEARER- AND-RADIO- 
BEARER RELEASE request indication sent from the TACF to BCFr to request to 
release the access link or handover link between the BCF and BCFr and between 
BCAF and BCF. 

Figure 501 is a table representing the detail of a BEARER-AND-RADIO- 
BEARER RELEASE response confirmation sent from the BCFr to TACF to indicate 
the completion of the release of the access link or hand over link. 

Figure 502 is a table representing the detail of a BEARER RELEASE 
response confirmation sent from the TACFv to TACFa to confirm the BEARER 
RELEASE request indication. . 

Figure 503 is a table representing the detail of a HANDOVER CONNECTION 
SETUP request indication sent from a TACFa to a BAFa to notify of a handover 
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initiation and to request to setup an ACCH. 

Figure 504 is a table representing the detail of a HANDOVER CONNECTION 
SETUP response confirmation sent from the BCF to the TACFa to confirm the 
HANDOVER CONNECTION SETUP request indication. 
5 Figure 505 is a table representing the detail of a BEARER SETUP request 

indication sent from the TACFa to a TACFv to setup an access bearer for the ACCH. 

Figure 506 is a table representing the detail of another BEARER SETUP 
request indication sent from the TACFv to the BCF to setup an access bearer for the 
ACCH. 

10 Figure 507 is a table representing the detail of a BEARER SETUP response 

confirmation sent from the BCF to the TACFv to confirm the BEARER SETUP request 
indication. 

Figure 508 is a table representing the detail of a BEARER-AND-RADIO- 
BEARER SETUP request indication sent from the TACFv to the BCFr. 
15 Figure 509 is a table representing the detail of a RADIO BEARER SETUP 

PROCEEDING request indication sent from the BCFr to the TACFv. 

Figure 510 is a table representing the detail of a RADIO BEARER SETUP 
REQUEST request indication. 

Figure 511 is a table representing the detail of another RADIO BEARER 
20 SETUP request indication sent from the TACFa to TACAF. 

Figure 512 is a table representing the detail of another RADIO BEARER 
SETUP request indication sent from the TACAF to BCAF. 

Figure 513 is a table representing the detail of a RADIO BEARER SETUP 
response confirmation sent from the BCAF to the TACAF to indicate the completion of 
25 the radio bearer setup for the new ACCH. 

Figure 514 is a table representing the detail of a RADIO BEARER RELEASE 
request indication sent from the TACAF to another BCAF to request to release a 
previous radio bearer. 
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Figure 515 is a table representing the detail of a RADIO BEARER RELEASE 
response confirmation sent from the BCAF to the TACAF to indicate the completion of 
the radio bearer release. 

Figure 516 is a table representing the detail of a HANDOVER CONNECTION 
RELEASE request indication sent from the TACFa to the BCFa to request to remove 
the previous bearer in the soft handover state. 

Figure 517 is a table representing the detail of a HANDOVER CONNECTION 
RELEASE response confirmation sent from the BCF to the TACF to confirm the 
HANDOVER CONNECTION RELEASE request indication. 

Figure 518 is a table representing the detail of a BEARER RELEASE request 
indication sent from the TACFa to TACFv to request to release the access bearer 

Figure 519 is a table representing the detail of another BEARER RELEASE 
request indication sent from the TACF to BCF to request to release the bearer. 

Figure 520 is a table representing the detail of a BEARER RELEASE 
response confirmation sent from the BCF to the TACF to confirm the BEARER 
RELEASE request indication. 

Figure 521 is a table representing the detail of a BEARER- AND-RADIO- 
BEARER RELEASE request indication sent from the TACF to BCFr to request to 
release the bearer between the BCF and BCFr and the radio bearer. 

Figure 522 is a table representing the detail of a BE ARER- AND -RAD I O - 
BEARER RELEASE response confirmation sent from the BCFr to TACAF to indicate 
the completion of the release of the bearer and radio bearer. 

Figure 523 is a table representing the detail of a BEARER RELEASE 
response confirmation sent from the TACFv to TACFa to confirm the BEARER 
RELEASE request indication. 

Figure 524 is a table representing the detail of a CODE REPLACEMENT 
request indication sent from a BCFr to a TACF to request change of codes. 

Figure 525 is a table representing the detail of another CODE 
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REPLACEMENT request indication sent from the visited TACF to a TACFa to request 
change of codes. 

Figure 526 is a table representing the detail of another CODE 
REPLACEMENT request indication sent from the TACF to a TACAF to request 
change of codes. 

Figure 527 is a table representing the detail of another CODE 
REPLACEMENT request indication sent from the TACAF to the BCAF to request to 
change of codes. 

Figure 528 is a table representing the detail of a CODE REPLACEMENT 
response confirmation sent from the BCAF to the TACAF to indicate the completion of 
the change of codes. 

Figure 529 is a table representing the detail of another CODE 
REPLACEMENT response confirmation sent from the TACAF to the TACFa to 
confirm the CODE REPLACEMENT request indication. 

Figure 530 is a table representing the detail of another CODE 
REPLACEMENT response confirmation sent from the TACFa to the TACFv to confirm 
the CODE REPLACEMENT request indication. 

Figure 531 is a table representing the detail of another CODE 
REPLACEMENT response confirmation sent from the TACF to the BCFr to confirm 
the CODE REPLACEMENT request indication. 

Figure 532 is a table representing the detail of a CELL CONDITION REPORT 
request indication sent from an MRRC to an RRC periodically to notify of the radio 
conditions of respective handover branches. 

Figure 533 is a table representing the detail of a TRANSMISSION POWER 
CONTROL request indication sent from a TACFa to TACFv to notify of the instructed 
transmission power. 

Figure 534 is a table representing the detail of another TRANSMISSION 
POWER CONTROL request indication sent from a TACFv to BCFr to notify of the 
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instructed transmission power. 

Figure 535 is a table representing the detail of an LAI UPDATE request 
indication sent from the visited SCF to the SDF. 

Figure 536 is a table representing the detail of a TERMINAL LOCATION 
5 UPDATE request indication sent from the SACF to the visited SCF. 

Figure 537 is a table representing the detail of another TERMINAL 
LOCATION UPDATE request indication sent from the MCF to the SACF. 

Figure 538 is a table representing the detail of an AUTHENTICATION 
INFORMATION RETRIEVAL request indication and an AUTHENTICATION 
10 INFORMATION RETRIEVAL response confirmation. 

Figure 539 is a table representing the detail of an AUTHENTICATION 
CHALLENGE request indication and the AUTHENTICATION CHALLENGE 
response confirmation transported between the LRCF and TACF; and the LRCF and 
SACF. 

15 Figure 540 is a table representing the detail of an AUTHENTICATION 

CHALLENGE request indication and an AUTHENTICATION CHALLENGE response 
confirmation transported between the TACF and TACAF; and the SACF and MCF. 

Figure 541 is a table representing the detail of an AUTHENTICATION 
request indication and an AUTHENTICATION response confirmation. 
20 Figure 542 is a table representing the detail of a start ciphering IF 

transported between the TACF and TACAF; and the LRCF to TACF. 

Figure 543 is a table representing the detail of another start ciphering IF 
transported between the LRCF and SACF. 

Figure 544 is a table representing the detail of a TMUI ASSIGNMENT 
25 request indication and a TMUI ASSIGNMENT response confirmation transported 
between the TACF and TACAF. 

Figure 545 is a table representing the detail of a TMUI QUERY request 
indication and a TMUI QUERY response confirmation. 
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Figure 546 is a table representing the detail of a TMUI MODIFY request 
'indication and a TMUI MODIFY response confirmation. 

Figure 547 is a table representing the detail of another TMUI ASSIGNMENT 
request indication and another TMUI ASSIGNMENT response confirmation 
transported between the LRCF to TACF. 

Figure 548 is a table representing the detail of another TMUI ASSIGNMENT 
request indication and another TMUI ASSIGNMENT response confirmation 
transported between the LRCF and SACF. 

Figure 549 is a table representing the detail of another TMUI ASSIGNMENT 
request indication and another TMUI ASSIGNMENT response confirmation 
transported between the SACF and MCF. 

Figure 550 is a table representing the detail of an IMUI RETRIEVAL request 
indication and an IMUI RETRIEVAL response confirmation transported between the 
LRCF and LRDF. 

Figure 551 is a table representing the detail of another IMUI RETRIEVAL 
request indication and another IMUI RETRIEVAL response confirmation transported 
between the SACF and LRCF 

Figure 552 is a table representing the detail of another IMUI RETRIEVAL 
request indication and another IMUI RETRIEVAL response confirmation transported 
between the MCF and SACF. 

Figure 553 is a table representing the detail of another IMUI RETRIEVAL 
request indication and another IMUI RETRIEVAL response confirmation transported 
between the TACF and LRCF. 

Figure 554 is a table representing the detail of another IMUI RETRIEVAL 
request indication and another IMUI RETRIEVAL response confirmation transported 
between the TACAF and TACF 

Figure 555 is a table representing the detail of the service access point 
identifier in a layer 3 compatible sub-sub-layer PDU. 
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Figure 556 is a table representing the detail of the ST in the layer 3 
compatible sub-sub-layer PDU. 

Figure 557 is a table representing the detail of the code type indicator in the 
layer 3 compatible sub-sub-layer PDU. 

Figure 558 is a table representing the detail of the reserved parameter in the layer 3 
compatible sub-sub-layer PDU. 

Figures 559 and 560 form a table representing various types of LLC protocol 
data units (PDUs). 

Figure 561 is a table representing the relationship between the length of CRC 
fields in an MAC PDU and channels through which corresponding frame is 
transmitted. 

Figure 562 is a table representing the bit coding of the ST field in a layer 1 
frame and the meaning thereof. 

Figure 563 is a table representing the bit coding of the BI field in a layer 1 
frame and the meaning thereof. 

Figure 564 is a table representing the bit coding of the uplink interference 
field in a layer 1 frame and the meaning thereof. 

Figure 565 is a. table representing the relationship between the usage of the 
PID field in a layer 1 frame and the range of PID value. 

Figure 566 is a table representing the bit coding of the U/C field in a layer 1 
frame and the meaning thereof. 

Figure 567 is a table representing the bit coding of the TN field in a layer 1 
frame and the meanings thereof. 

Figure 568 is a table representing the bit coding of the MO field in a layer 1 
frame and the meanings thereof. 

Figure 569 is a table representing the relationship between the length of CRC 
fields and channels through which corresponding frames are transmitted. 

Figure 570 is a list representing various messages belonging to CC 
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(call/connection control) entity message. 

Figure 571 through 573 form a list representing information elements 
constituting an alerting message. 

Figure 574 through 576 form a list representing information elements 
constituting a call proceeding message. 

Figure 577 through 581 form a list representing information elements 
constituting a connect message. 

Figure 582 is a list representing information elements constituting a connect 
acknowledge message. 

Figures 583 through 585 form a list representing information elements 
constituting a progress message. 

Figures 586 through 594 form a list representing information elements 
constituting a setup message. 

Figure 595 is a list representing information elements constituting a release 
message. 

Figure 596 is a list representing information elements constituting a release 
complete message. 

Figure 597 is a list representing information elements constituting an 
information message. 

Figure 598 is a list representing a message (mobility facility message) 
belonging to the MM-T (terminal mobility management) entity message. 

Figure 599 is a list representing the generic formats of the mobility facility 
message. 

Figures 600 and 601 form a list representing information elements 
constituting a mobility facility message transferred from a mobile station to the 
network for requesting terminal location registration. 

Figure 602 is a list representing information elements constituting a mobility 
facility message indicating "return result" issued when the terminal location has been 
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normally registered. 

Figure 603 is a list representing information elements constituting a mobility 
facility message indicating "return error" issued when an abnormality, for example, an 
application error has occurred. 

Figure 604 is a list representing information elements constituting a mobility 
facility message indicating "return error" when an abnormality, for example, a 
discrepancy of an information element has occurred. 

Figure 605 is a list representing information elements constituting a mobility 
facility message transferred for notifying a mobile station of the TMUI allocated to the 
mobile station. 

Figure 606 is a list representing information elements constituting a mobility 
facility message indicating "return result" issued when the TMUI has been normally 
assigned. 

Figure 607 is a list representing information elements constituting a mobility 
facility message indicating "return error" issued when an abnormality, for example, an 
application error has occurred. 

Figure 608 is a list representing information elements constituting a mobility 
facility message indicating "return error" when an abnormality, for example, a 
discrepancy of an information element has occurred. 

Figures 609 and 610 form a list representing information elements 
constituting a mobility facility message transferred from the network to a mobile 
station for authenticating the mobile station by the mobile service switching center. 

Figure 611 is a list representing information elements constituting a mobility 
facility message indicating "return result" issued when the authentication has been 
normally requested. 

Figure 612 is a list representing information elements constituting a mobility 
facility message indicating "return error" issued when an abnormality, for example, an 
application error has occurred. 
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Figure 613 is a list representing information elements constituting a mobility 
facility message indicating "return error" when an abnormality, for example, a 
discrepancy of an information element has occurred. 

Figure 614 is a list representing information elements constituting a mobility 
5 facility message transferred for notifying a mobile station of ciphering onset. 

Figure 615 is a list representing information elements constituting a mobility 
facility message indicating "return result" issued when the ciphering onset has been 
normally notified. 

Figure 616 is a list representing information elements constituting a mobility 
10 facility message indicating "return error" issued when an abnormality, for example, an 
application error has occurred. 

Figure 617 is a list representing information elements constituting a mobility 
facility message indicating "return error" when an abnormality, for example, a 
discrepancy of an information element has occurred. 
15 Figure 618 is a list representing information elements constituting a mobility 

facility message transferred for inquiring of a mobile station as to the IMUI of the 
mobile station. 

Figure 619 is a list representing information elements constituting a mobility 
facility message indicating "return result" issued when the IMUI has been normally 
20 inquired. 

Figure 620 is a list representing information elements constituting a mobility 
facility message indicating "return error" issued when an abnormality, for example, an 
application error has occurred. 

Figure 621 is a list representing information elements constituting a mobility 
25 facility message indicating "return error" when an abnormality, for example, a 
discrepancy of an information element has occurred. 

Figure 622 is a list representing messages belonging to RBC entity message. 

Figure 623 is a list representing classification of RBC entity message. 
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Figure 624 is a list representing the format of radio bearer setup message. 
Figure 625 is a list representing the format of radio bearer release message. 
Figure 626 is a list representing the format of radio bearer release complete 
message. 

5 Figure 627 is a list representing the format of handover command message. 

Figure 628 is a list representing the format of handover response message. 

Figure 629 is a list representing a message (radio resource facility message) 
belonging to RRC entity message. 

Figure 630 is a list representing the format of the RRC facility message. 
10 Figure 631 is a list representing TAC entity messages. 

Figure 632 is a list representing the relationship between TAC entity message 
and information flow. 

Figure 633 is a list representing the format of a terminal association setup 
message. 

15 Figure 634 is a list representing the format of a terminal association connect 

message. 

Figure 645 is a list representing the bit coding manner of a protocol 
discriminator in the CC entity message. 

Figures 646 and 647 form a list representing the bit coding manner of a 
20 message type identifier. 

Figures 648 and 649 form a list representing the bit coding manner of a 
variable length information element according to FPLMTS. 

Figure 650 is a list representing the bit coding manner of a broadband locking 
shift information element. 
25 Figure 651 is a list representing the bit coding manner of a broadband non- 

locking shift information element. 

Figures 652 through 654 form a list representing the bit coding manner of an 
AAL parameter information element. 
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Figure 655 is a list representing the bit coding manner of an ATM traffic 
descriptor information element. 

Figure 656 is a list representing the bit coding manner of a broadband bearer 
capability information element. 

Figure 657 is a list representing the bit coding manner of a broadband high 
layer information element. 

Figures 658 through 660 form a list representing the bit coding manner of a 
broadband low layer information element. 

Figure 661 is a list representing the bit coding manner of a called party 
number information element. 

Figure 662 is a list representing the bit coding manner of a called party sub- 
address information element. 

Figures 663 and 664 form a list representing the bit coding manner of a calling 
party number information element. 

Figure 665 is a list representing the bit coding manner of a calling party sub- 
address information element. 

Figure 666 is a list representing the bit coding manner of a connection 
identifier information element. 

Figure 667 is a list representing the bit coding manner of an end-to-end 
transit delay information element. 

Figure 668 is a list representing the bit coding manner of a QOS parameter 
information element. 

Figure 669 is a list representing the bit coding manner of a broadband repeat 
indicator information element. 

Figure 670 is a list representing the bit coding manner of a transit network 
selection information element. 

Figure 671 is a list representing the bit coding manner of an OAM traffic 
descriptor information element. 
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Figure 672 is a list representing the bit coding manner of an MM-T specific 
information elements. 

Figure 673 is a list representing parameters of a candidate zone information 
for call attempt or acceptance. 

Figure 674 is a list representing parameters of an in-use zone information. 

Figure 675 is a list representing parameters of an added zone information for 

DHO. 

Figure 676 is a list representing parameters of a deleted zone information for 

DHO. 

Figure 677 is a list representing parameters of a HHO zone information. 

Figure 678 is a list representing parameters of an outer loop information. 

Figure 679 is a list representing parameters of a quality deterioration 
notification information. 

Figure 680 is a list representing the bit coding manner of a TAC entity 
message. 

Figure 681 is a list representing TAC entity message specific parameters. 

Figure 682 is a list representing the bit coding manner of a terminal 
association setup message specific parameter. 

Figure 683 is a list representing the bit coding manner of a paging response 
message specific parameter. 

Figure 684 is a list representing the bit coding manner of a terminal 
association release message specific parameter. 

Figure 685 is a list representing information elements which may be 
contained in subfields of TAC entity message specific parameters. 

Figure 686 is a list representing the bit coding manner of a cause information 

element. 

Figure 687 is a list representing the bit coding manner of a mobile station type 
information element. 
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Figure 688 is a list representing the bit coding manner of a paged MS ID 
information element. 

Figure 689 is a list representing the bit coding manner of a paging ID 
information element. 

Figure 690 is a list representing types of BC entity messages. 

Figure 691 is a list representing a classification of BC entity messages. 

Figure 692 is a list representing structural information elements of a link 
setup requested message. 

Figure 693 is a list representing structural information elements of a link 
setup message. 

Figure 694 is a list representing structural information elements of a link 
setup proceeding message. 

Figure 695 is a list representing structural information elements of a link 
setup response message. 

Figure 696 is a list representing structural information elements of a link 
facility message sent from the MSCNW to the BTS, 

Figure 697 is a list representing structural information elements of another 
link facility message sent from the BTS to the MSCNW. 

Figure 698 is a list representing structural Information elements of a link 
release message. 

Figure 699 is a list representing structural information elements of a link 
release complete message. 

Figure 700 is a list representing the combinations of the fundamental 
information elements in the link setup message in various uses. 

Figure 701 is a list representing the combinations of the fundamental 
information elements in the link setup proceeding message in various uses. 

Figure 702 is a list representing the combinations of the fundamental 
information elements in the link setup response message in various uses. 
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Figure 703 and 704 form a list representing the combinations of the 
fundamental information elements in the link facility message in various uses. 

Figure 705 and 706 form a list representing the combinations of the 
fundamental information elements in the other link facility message in various uses. 
5 Figure 707 is a list representing a message belonging to the BSM entity 

message. 

Figure 708 is a list representing structural information elements of a paging 
message. 

Figure 709 is a list representing the format of a link ID information element. 
10 Figure 710 is a list representing the format of a TCH setup request < 

information element without frequency indication. 

Figure 711 is a list representing the format of a TCH setup request 
information element without frequency indication. 

Figure 712 is a list representing the format of a TCH setup request 
15 information element with frequency indication. 

Figure 713 is a list representing the format of a DHO branch addition request 
information element. 

Figure 714 is a list representing the format of an intra-BS DHO branch 
addition request information element. 
20 Figure 715 is a list representing the format of an ACCH setup request 

information element. 

Figure 716 is a list representing the format of a TCH setup acceptance 
information element without frequency indication. 

Figure 717 is a list representing the format of a TCH setup acceptance 
25 information element without frequency indication. 

Figure 718 is a list representing the format of a TCH setup acceptance 
information element with frequency indication. 

Figure 719 is a list representing the format of a TCH setup response 
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information element without frequency indication. 

Figure 720 is a list representing the format of a TCH setup response 
information element without frequency indication. 

Figure 721 is a list representing the format of a TCH setup response 
information element with frequency indication. 

Figure 722 is a list representing the format of a DHO branch addition 
response information element. 

Figure 723 is a list representing the format of an intra-BS DHO branch 
addition response information element. 

Figure 724 is a list representing the format of an ACCH setup response 
information element. 

Figure 725 is a list representing the format of an intra-BS DHO branch 
addition request information element. 

Figure 726 is a list representing the format of an intra-BS DHO branch 
deletion request information element. 

Figure 727 is a list representing the format of an intra-BS HHO branch 
addition request information element. 

Figure 728 is a list representing the format of an ACCH release request 
information element. 

Figure 729 is a list representing the format of a frequency replacement setup 
request information element without frequency indication. 

Figure 730 is a list representing the format of a frequency replacement setup 
request information element* with frequency indication. 

Figure 731 is a list representing the format of a setup completion notification 
information element. 

Figure 732 is a list representing the format of an intra-BS HHO branch 
deletion response information element. 

Figure 733 is a list representing the format of an intra-BS HHO branch 
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addition response information element. 

Figure 734 is a list representing the format of an ACCH release response 
information element. 

Figure 735 is a list representing the format of a frequency-indicated frequency 
replacement setup response information element. 

Figure 736 is a list representing the format of a frequency-indicated frequency 
replacement setup request information element. 

Figure 737 is a list representing the format of a frequency-non-indicated 
frequency replacement setup acceptance information element. 

Figure 738 is a list representing the format of a frequency-non-indicated 
frequency replacement setup response information element. 

Figure 739 is a list representing the format of a code replacement request 
information element. 

Figure 740 is a list representing the format of a TCH release request 
information element. 

Figure 741 is a list representing the format of an SDCCH release request 
information element. 

Figure 742 is a list representing the format of a cause information element. 

Figure 743 is a list representing the format of an SDCCH setup request 
information element. 

Figure 744 is a list representing the format of an LAI setup request 
information element. 

Figure 745 is a list representing the format of a protocol discriminator of a BC 
entity message. 

Figure 746 is a list representing the format of a message type identifier of a 
BC entity message. 

Figure 747 is a list representing the format of a protocol discriminator of a 
BSM entity message. 
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Figure 748 is a list representing the format of a message type identifier of a 
BSM entity message. 

Figure 749 is a list representing the format of a number type parameter indicating the 
type of number which is included at octet 4 and later octets in the paged MS ID shown 
in Figure 252. 

Figure 750 is a list representing the format of a number length parameter 
indicating the length of number which is included at octet 4 and later octets in the 
paged MS ID shown in Figure 252. 

Figure 751 is a block diagram showing a part of the mobile communications 
system in which a signal is ciphered and successfully received. 

Figure 752 is a block diagram similar to Figure 751, but the ciphered signal is 
not successfully received. 

Figure 753 is a block diagram showing a part of the mobile communications 
system for the description of an encipherment procedure. 

Figure 754 is a block diagram representing the operation of the encipherment 
procedure in the invented system. 

Figure 755 is a ciphering procedure sequence diagram in normal operation 
where the network and the mobile station commence to encipher transmitted signals 
and to decipher received signals after transmission of an enciphering onset request 
from the network to the mobile station. 

Figure 756 is a sequence diagram representing a disadvantage of the 
ciphering procedure sequence represented in Figure 755. 

Figure 757 is a ciphering procedure sequence diagram in normal operation 
according to a control method described in section 3.1. 

Figure 758 is a sequence diagram representing an advantage of the ciphering 
procedure sequence according to a control method described in section 3.1. 

Figure 759 is a schematic sequence diagram representing an encipherment 
method in a mobile communications system, in which only a specific encipherment 
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manner is adopted. 

Figure 760 represents a schematic sequence diagram representing a selection 
of encipherment manner by negotiation between mobile station and network in 
accordance with a control method described in section 3.2. 
5 Figures 761 and 762 constitute a detailed sequence diagram representing the 

control method described in section 3.2. 

Figure 763 is a diagram representing a conventional method for establishing 
access link for a mobile station when the mobile station locates at a position where 
intra-cell diversity handover can be carried out. 
10 Figure 764 is a diagram representing a conventional method for establishing 

access link for a mobile station when the mobile station locates at a position where 
inter-cell diversity handover can be carried out. 

Figure 765 is a sequential flow diagram representing a series of information 
flows transported between the mobile station and the network for carrying out the 
15 access link setup procedure. 

Figure 766 is a sequential flow diagram representing a series of information 
flows transported between the mobile station and the network for entering the intra- 
cell diversity handover procedure. 

Figure 767 is a sequential flow diagram representing a series of information 
20 flows transported between the mobile station and the network for entering the intra- 
cell diversity handover procedure. 

Figure 768 is a diagram representing features of the invented system for 
starting diversity handover simultaneously with the access link setup. 

Figure 769 is a sequential flow diagram representing the start of intra-cell 
25 diversity handover simultaneously with the access link setup. 

Figure 770 is a sequential flow diagram representing the start of inter-cell 
diversity handover simultaneously with the access link setup. 

Figure 771 is a diagram representing a situation where transition to diversity 
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handover is necessary immediately after the completion of branch replacement. 

Figure 772 is a sequential flow diagram representing a series of information 
flows transported between the mobile station and the network for carrying out the 
branch replacement. 

Figure 773 is a sequential flow diagram representing an operation in the 
invented system which is carried out when the mobile station moves to a diversity 
handover zone. 

Figure 774 is a diagram representing an embodying method for controlling 
branch structure and frequency band in the system according to the presented 
invention when a call attempt occurs to or from a mobile station that can treats a 
plurality of calls simultaneously and is treating a call. 

Figure 775 is a sequential flow diagram representing the operation 
exemplified in Figure 774 of the system. 

Figure 776 is a diagram representing another embodying method for 
controlling branch structure and frequency band in the system according to the 
presented invention when a call attempt occurs to or from a mobile station that can 
treats a plurality of calls simultaneously and is treating a call. 

Figure 777 is a diagram representing another embodying method for 
controlling branch structure and frequency band in the system according to the 
presented invention when a call attempt occurs to or from a mobile station that can 
treats a plurality of calls simultaneously and is treating a call. 

Figure 778 is a sequential flow diagram representing the operation 
exemplified in Figure 776 of the system. 

Figure 779 is a sequential flow diagram representing the operation 
exemplified in Figure 777 of the system. 

Figure 780 is a diagram representing a control method executed in the system 
according to the present invention when a trigger of handover occurs to the mobile 
station which is treating a plurality of calls. 
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Figure 781 is a diagram representing another control method executed in the 
system according to the present invention when a trigger of handover occurs to the 
mobile station which is treating a plurality of calls. 

Figure 782 is a sequential flow diagram representing the operation 
exemplified in Figure 780 of the system. 

Figure 783 is a sequential flow diagram representing the operation 
exemplified in Figure 781 of the system. 

Figure 784 is a diagram representing another control method executed in the 
system according to the present invention when a trigger of handover occurs to the 
mobile station which is treating a plurality of calls. 

Figure 785 is a sequential flow diagram representing the operation 
exemplified in Figure 784 of the system. 

Figure 786 is a sequential flow diagram representing an operation for the 
start of inter-cell diversity handover simultaneously with the access link setup. 

Figure 787 is a flowchart of an operation of the mobile station, which is 
appropriate to realizing the operation in Figure 786. 

Figure 788 is a sequential flow diagram representing a conventional operation 
for access link setup for a mobile station when the mobile station is located at the 
position where it can carry out intra-cell diversity handover. 

Figure 789 is a flowchart of an operation of the mobile station for realizing the 
operation in Figure 786. 

Figure 790 is a diagram showing a part of the invented system for describing 
the ACCH replacement. 

Figure 791 is a sequential diagram representing an alteration of the ACCH 
replacement procedure, similar to that shown in Figures 53 and 54, but is not 
accompany with the replacement of wired access link. 

Figure 792 is a diagram for describing the uplink transmission power control 
for the mobile stations in the invented system. 
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Figure 793 and 794 are diagrams representing a method for reassigning code 



resources in section 3.10. 



BEST MODE FOR CARRYING OUT INVENTION 



5 



1. 



GENERAL DESCRIPTION OF SYSTEM 



1.1. 



INTRODUCTION 



This system is a mobile communications system wherein W-CDMA (wide-band 
code division multiple access) is adopted for the radio access manner in order to 
enhance efficiency for frequency utilization, to process multiplexed and high-rate 
10 signals flexibly, and to improve the communication quality to the level equivalent to 
fixed networks. 



15 communications system in accordance with an embodiment of the present invention 
will be described. As shown in Figure 1, the system comprises mobile stations MS 
and a radio base station system BSS. The base station system BSS is constituted of 
base transceiver systems BTS and a mobile communications control center MCC 
connected to the base transceiver systems via cable transmission lines HW. The 

20 mobile stations MS include a wide-purpose mobile station, a small portable mobile 
station 2 connected to a personal computer, a small portable mobile station 3 that is a 
traditional portable telephones, and so on. The mobile communications control center 
MCC is connected with the personal computers via a fixed PSTN or ISDN, telephone 
network, or LAN. With such a structure, high-quality voice data, N-ISDN, packets or 

25 modem signals may be transformed. 



1.2 



ENTIRE SYSTEM STRUCTURE 



First, with reference to Figure 1, the entire structure of a W-CDMA mobile 



1.3 ABBREVIATIONS 

Glossary of the abbreviations used in the present specification is indicated in 
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Figure 265. In addition, the technical terms, which are used in the present 
specification but not defined, comply with ITU-T Recommendation Q.65. 

2. ACCESS INTERFACES 

2.1 GENERAL DESCRIPTION OF ACCESS INTERFACES 

Chapter 2 prescribes access interfaces of W-CDMA mobile communications 
system. The access interfaces in this system include, as shown in Figure 2, a radio 
interface served for communication between the mobile station MS and the base 
transceiver systems BTS, and a BTS-MCC interface served for communication 
between the base transceiver systems BTS and the mobile communications control 
center MCC. Although this specification describes the W-CDMA mobile 
communications system to enable any person skilled in the art to make or use the 
present invention, the present invention is not intended to be limited to the described 
W-CDMA mobile communications system, but is intended to cover any mobile 
communications system according to any kind of access manner within the attached 
claims. 

To prescribe the interfaces, this chapter includes the following items: 

1) Services Provided by the System and the System Capabilities in 
Compliance with the Protocols 

2) System Functional Structure and Control Manners for Realizing the 
Services and System Capabilities 

3) Rules for Reference Model Structure and Interfaces in Compliance with the 
Protocols 

4) Physical Architecture and Physical Condition of the Radio Interface 

5) Signal Transfer Protocol for the Radio Interface (Layer-2) 

6) Control Protocol for the Radio Interface (Layer-3) 

7) Physical Architecture and Electrical Condition of the BS-MCC Interface 

8) Information Transmission Protocol for the BS-MCC Interface (ATM Layer 
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and AAL type-2) 

9) Signal Transfer Protocol for the BS-MCC Interface (AAL) 

10) Control Protocol for the BS-MCC Interface (Layer-3) 

The control manners and protocol specifications described in this chapter 
comply with recommendation drafts Q.FNA, Q.FIF, Q.FSA, and Q.FSR prepared on 
the basis of the discussions at TTC IMT-2000 Study Committee, Network Aspect ad 
hoc. 

2.2 FEATURES OF ACCESS INTERFACES 

Next, features of access interfaces will be described. 

2.2.1 HANDOVER 

A plurality of radio zones are arranged in a mobile communications system 
and each zone is provided with a base station. To start communication between one of 
the base stations and a mobile station, a kind of wireless channel called a perch 
channel is employed. More specifically a plurality of perch channels of which the 
frequency bands are different from each other are established between the base station 
and the mobile station for selecting one of traffic channels for actual communication. 
That is to say, the traffic channel TCH for transporting voice or messages is selected by 
virtue of the perch channels. 

When a mobile station MS travels across the boundary of radio zones, lowered 
is the level of the electric field of the radio wave received from the base station of the 
zone from which the mobile station has exited, thereby depreciating the 
communication quality. Accordingly, it is necessary for the mobile station to alter the 
currently communicating base station to a new base station from which the reception 
is more excellent, so that the traffic channel TCH employed by the mobile station MS 
is replaced. This replacement is called handover. 

In order to facilitate handover, it is preferable that the frequency band of the 
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former traffic channel TCH and that of the new traffic channel TCH are the same with 
each other. In accordance with traditional mobile communications, a mobile station 
MS measures the respective levels of the electric fields of in relation to circumferential 
perch channels and selects candidate base stations for handover. The mobile station 
5 then informs the network of a handover request designating the candidate base 
stations for handover. 

However, if the traffic channel TCH of the same frequency band as that of the 
currently communicating channel is not preselected for candidate cells in 
circumferential zones, it is impossible that the cells serve the mobile station although 
sB 10 the mobile station has transmitted the handover request. Therefore, it is necessary 

lj. for the network to exclude, from the candidate cells, the cell without preselection of 

~jz traffic channel TCH of the same frequency band as that of the currently 

?T communicating traffic channel in accordance with the prior art. 

^ Accordingly, in the present system, the mobile station MS sends the network a 

l Jf 15 handover request wherein previously excluded is the cell that does not preselect the 

W traffic channel TCH at the same frequency band as the current communication. Next, 

Q this feature will be described with reference to Figure 259 in more detail. 

Figure 259 represents an example of handover procedure in the present 
communications system. In Figure 259, a mobile station MS is communicating at a 
20 frequency band f2 in a zone 1. Assume the mobile station MS travels from zone 1 to 
zone 2; and strength ranking of the reception level (level of the electric field of the 
received wave) measured by the mobile station MS at the frequency band f2 is zone 2, 
zone 3, and zone 4. In this case, the traditional handover request designates that the 
primary candidate zone is zone 2, the secondary candidate is zone 3, and the third 
25 candidate is zone 4. 

On the contrary, according to the present communications system, 
broadcasting information indicating the preselection condition of the traffic channels 
TCH with reference to the respective circumferential zones is informed to the mobile 
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station MS as will be described at section 2.5.2.4.2.6. Using the broadcasting 
information, the mobile station recognizes the zone in which the traffic channel TCH 
at the same frequency band as the current communication is not preselected, so as to 
exclude the recognized zone from the handover candidates. Therefore, the mobile 
station MS in the embodiment informs the network of the handover request 
designating that the primary candidate zone is zone 3 and the secondary candidate is 
zone 4. 

As will be described in section 2.3.2.2.4, the present communications system 
can carry out a handover branch addition, handover branch deletion, and branch 
replacement handover. The above-discussed procedure in view of the preselection 
status of traffic channel may be carried out at the handover branch addition and the 
branch replacement handover. 

With reference to Figure 37, description will be given with respect to an 
example of sequential operation wherein the mobile station MS completes to request 
handover. In Figure 37, MRRC, MRTR, RFTR, and RRC designate functional entities 
arranged in the mobile station MS. MRRC controls the radio resources. MRTR 
controls an encipherment procedure and outputting procedure and measures the radio 
environment, that is, the respective reception levels in relation to the circumferential 
radio zones. RFTR controls an encipherment procedure and outputting procedure. 
RRC controls the radio resources. 

As shown in Figure 37, MRRC provides a CELL CONDITION 
MEASUREMENT request indication indicating a request for measurement of the 
wireless environment to MRTR at periodic intervals. Upon the reception of it, MRTR 
measures the respective reception levels in relation to the circumferential radio zones 
and transmits MRRC the measurement result as a CELL CONDITION 
MEASUREMENT response confirmation. Next, MRRC compares the reception level 
of the currently communicating wireless channel with the reception levels of the 
wireless channels from the circumferential zones. If the latter is stronger than the 
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former, MRRC conducts the following process to execute handover. 

MRRC excludes the zone to which the traffic channel is not preselected on the 
basis of the broadcast information, and ranks the zones in strength order with 
reference to the same frequency band as the current communication. Then, MRRC 
5 rearranges the remaining zones in order of strength rank, the remaining zones being 
the candidates for handover; generates a NON-SOFT HANDOVER EXECUTION 
TRIGGER request indication designating the strength order of the remaining zones; 
and sends the NON-SOFT HANDOVER EXECUTION TRIGGER request indication to 
TACF in the network via RRC. 

10 The notification of non-soft handover execution trigger requirement to TACF 

triggers the handover. Then, the network selects the base station among the 
candidate base stations in order to execute the handover and notifies the mobile 
station MS about the selected base station, thereby activating the traffic channel in 
relation to the base station. Accordingly it is possible for the network to exclude 

15 complicated control procedures, e.g., detection procedure of the frequency band that 
the mobile station MS uses for communication and determination procedure as to 
whether the traffic channel TCH of the same frequency band is preselected by the 
candidate zone or not. Subsequent operation following the handover trigger is 
illustrated in Figure 49. 

20 

2.2.2 REPLACEMENT OF ACCH 

Associated control channel (ACCH) is a kind of control channel utilizing the 
same radio resources as those for the traffic channel TCH that is used for voice or data 
transportation. By means of ACCH, control signals may be transported between the 
25 mobile station MS and base station BS. 

There is a kind of communications system wherein one mobile station MS can 
treat a plurality of calls simultaneously. In addition, there is another kind of 
communications system wherein one mobile station MS realizes a call using a plurality 
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of radio physical channels. These systems are suitable for radio bearer services. In 
these kinds of systems, sometimes it is necessary that control signals may be 
transported between the mobile station MS, which is treating the plurality of calls, 
and base station BS.. 

For this purpose, it would be possible to form ACCHs corresponding to all of 
the plurality of calls for transporting control signals, ACCHs being constituted of 
wireless communication resources which are also utilized by the traffic channels. 
However, this technique needs many hardware elements for transporting control 
signals and complicated control procedures for managing the transportation order of 
control signals in the plurality of ACCHs. 

Accordingly, in the present communications system, when the mobile station 
treats a plurality of calls using a plurality sets of wireless communication resources 
which are also being utilized by a plurality of traffic channels, one set of the wireless 
communication resources is selected and then the control channel, which uses this set, 
is established between the mobile station and the base station for transporting the 
control information therebetween. 

The method for establishing ACCH in the communications system will be 
described next in more detail. 

Figure 260 illustrates an example of mobile communications system wherein a 
mobile station treats a plurality of calls. In Figure 260, traffic channels respectively 
corresponding to the plurality of calls are established between a mobile station MS and 
a base station BS, whereby the calls can be treated simultaneously. For treating the 
multiple calls, only one ACCH (e.g., ACCH1 in Figure 260) is selected from the 
multiple ACCHs corresponding to multiple traffic channels, and shared for 
transporting all control signals in relation to the mobile station in the system. 

Therefore, by virtue of the system, it is possible to reduce the number of 
hardware elements for transporting control signals in comparison with the case that 
all of the plurality of calls respectively utilize multiple ACCHs, corresponding to the 
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multiple traffic channels. In addition, it is possible to exclude complicated control 
procedures, e.g., management of the transportation order of control information in the 
plurality of ACCHs. 

In the system shown in Figure 260, however, when a set of wireless 
communication resources involved in the single ACCH is released due to the release of 
one of the traffic channels by the ending of the call, it is difficult to secure the ACCH to 
continue the other call. The same problem may occur when the transmission rate in 
the ACCH is altered. 

Accordingly, in addition to sharing the single ACCH by the multiple traffic 
channels for realizing the multiple calls simultaneously by the single mobile station 
MS, when the single set of wireless communication resources involved in the single 
ACCH is released, the ACCH is replaced by another ACCH. Figure 261 illustrates 
functional entities to realize the ACCH replacement of the system. In this 
illustration, the mobile station MS treats two calls, namely first call and second call, 
simultaneously, the first and second calls utilizing the traffic channel TCH1 or TCH2 
respectively. However, only one associated control channel ACCH1 is served for 
transporting control information between the network and the mobile station MS in an 
initial state. 

As shown in Figure 261, the mobile station MS includes functional entities 
called TACAF, BCAF1, and BCAF2. TACAF controls the access and instructs to 
release and establish the ACCHs. BCAF1 controls the radio bearer for the first call 
while BCAF2 controls the radio bearer for the second call. BACF1 and BACF2 
execute to release and establish the corresponding ACCHs, respectively. 

The base station BS includes functional entities called BCFrl and BCFr2 
while the network includes a functional entity called TACF which functions as a base 
station controller (BSC). BCFrl and BCFr2 respectively control the radio bearers for 
the first and second calls and execute to activate and release the corresponding ACCHs. 
TACF controls the access and instructs to activate and release the ACCHs. 
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Assume that the second call utilizing the traffic channel TCH2 should be 
continued while the first call utilizing the traffic channel TCH1 is ended. The ACCH 
replacement procedure will be described in the sequential diagram in Figure 262. 

In the procedure, first, once the first call utilizing the traffic channel TCH1 is 
5 ended, the traffic channel TCH1 is released. Once TACF detects the release trigger of 
the traffic channel TCH1, TACF determines whether ACCH1 on the same physical 
channel as the traffic channel TCH1 is used or not. In addition, TACF determines 
whether an ACCH is necessary for continuing the traffic channel TCH2 although the 
traffic channel TCH1 is released. 
10 If those determinations are affirmative, TACF sends BCFr2, which is in 

charge of the second call, an activation request for ACCH2 that is accompanying with 
the traffic channel TCH2. In response, BCFr2 activates ACCH2. Then, BCFr2 
sends a completion report indicating the completion of the activation of ACCH2 to 
TACF. 

15 Upon the completion report, TACF informs TACAF of a replacement request 

for switching to ACCH2. The reception of the replacement request causes TACAF to 
inform BACF2 of an establishment request for ACCH2, so that BCAF2 establishes 
ACCH2. Additionally, TACF informs BCAF1 of a release requirement for ACCH1, so 
that BCAF1 releases ACCH1. 

20 Next, TACAF sends TACF a replacement completion report indicating the 

completion of the replacement of ACCH. Then, TACF informs BCFrl of a request for 
releasing ACCH1, so that BCFrl releases ACCH. Consequently, the ACCH 
replacement is completed, so that transportation of control information between the 
mobile station and the network may be accomplished via ACCH2, which uses the same 

25 radio resources as the traffic channel TCH2. The ACCH replacement procedure will 
be described again in more detail at section 2.4.3.5.7. 
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2.2.3 PROCEDURES FOR ENCIPHERMENT ONSET MOMENT 

NOTIFICATION 

Since mobile communications are carried out over the air, signals are 
sometimes ciphered (encoded into cipher) at the source terminal to be preserved from 
intercept or manipulation by a third party. The destination terminal deciphers the 
ciphered signals (decodes them to make out the meaning). 

However, in communication of the enciphered signals (control signals), if the 
onset moment of the encipherment is unclear, it is impossible to decipher smoothly. 
That is, if the onset time of the decipherment may be misestimated, the meaning of 
signals cannot be made out. 

With reference to Figures 751 and 752, a trouble occurring in relation to 
timing error of encipherment onset and decipherment onset will be described. 

Figure 751 represents a mobile communications system in which an 
encipherment transfer is conducted. Assume that a mobile station MS can receive 
signals using a diversity handover technique. As illustrated in Figure 751, a base 
station controller RNC distributes the same series of transmission signals (non- 
enciphered signals) to a plurality of radio base stations BS1 to BS3 for diversity 
handover of the mobile station. Then, the radio base stations BS1 to BS3 enciphers 
the series of signals and transmits the enciphered signals to the single mobile station 
MS. 

In this system, since the respective base stations execute the encipherment 
processes, there is likelihood that the onset moment of the encipherment varies among 
the base stations. It is possible in theory to align the encipherment onset moment 
among the base stations, but difficult in practice. More specifically, the base station 
controller RNC should negotiate with the radio base stations BSl to BS3 in advance 
for matching the encipherment onset time. However, it is difficult in practice to 
prevent the timing error completely. 

As described above, it is necessary that the same kind of signal (i.e., 
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enciphered transmission signal or non-enciphered transmission signal) should be 
transmitted from all of the base stations BS1 to BS3 for realizing the diversity 
combining at the mobile station. However, layer 1 of the OSI reference model 
supervises between the mobile station and the respective base stations although layer 
3 supervises between the mobile station MS and the base station controller RNC or 
between the mobile station MS and the mobile service switching center MSC. 

Accordingly, as shown in Figure 752, if the enciphermerit is conducted for 
Layer 1 of the OSI reference model, a group of base stations (e.g., BS2 and BS3) 
transmit enciphered signal while another group of the base stations (e.g., BSl) 
transmit non-enciphered signal at the same time. Therefore, it is impossible for a 
type of mobile station, which cannot process in parallel the enciphered signal and 
non-enciphered signal in view of structure simplification and production-cost reduction, 
to conduct diversity combining. 

Therefore, it is an object to provide a communications system wherein even a 
type of mobile station, which cannot process in parallel an enciphered signal and non- 
enciphered signal, can carry out diversity reception securely. In the system, the 
mobile station MS and the mobile communications control center MCC mutually 
inform of the encipherment moment, so as to appropriately decipher for errorless 
communication. 

With reference to the functional model in Figure 64, the encipherment onset 
moment notification procedures will be described. As shown in Figure 64, the mobile 
station MS includes functional entities called UIMF, MCF, and TACAF. UIMF stores 
information on the station user and serves the user authentication and encipherment 
calculation. MCF functions as an interface with the network for realizing services 
that are not related to calls. TACAF controls the access processes to the mobile 
station terminal, e.g., the origination, paging, and so on. 

The network on the other hand includes functional entities called SACF, 
TACF, LRCF, and LRDF. SACF is connected with MCF to function as an interface 
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with the mobile terminal for realizing services that are not related to calls. TACF is 
connected with TACAF to control the access processes to the mobile station terminal, 
e.g., the origination, paging, and so on. LRCF is connected with TACF and SACF to 
control mobility management. LRDF stores various data on mobility management. 
5 With such a structure, prior to the mutual notification of the encipherment 

onset, a user authentication procedure (refer to section 2.4.5.1) is executed as shown in 
Figure 63. In execution of the user authentication procedure, a certificated 
encipherment key is previously stored at UIMF and LRDF of the network and mobile 
terminal and delivered to TACAF, MCF, TACF, and SACF. 

10 Then, mutual notification of the encipherment onset time is carried out in 

accordance with the sequence shown in Figure 65. More specifically, first, LRCF of 
the network sends a START CIPHERING request indication for indicating that the 
network will start encipherment to TACAF and MCF of the mobile terminal via TACF 
and SACF of the network. Consequently, the mobile terminal can recognize that the 

15 succeeding signals transmitted from the network will be ciphered. After the 
transmission of the START CIPHERING request indication, TACF and SACF of the 
network cipher succeeding signals according to a preselected encipherment procedure 
using a preselected ciphering key. Once the mobile terminal receives the enciphered 
signal, TACAF and MCF controls the decipherment of the received signals. In 

20 advance to the decipherment, TACAF and MCF receive the encipherment key from 
UIMF to carry out the decipherment. Accordingly, the downlink signal transmitted 
from the network can be transported in secret and interpreted by only the mobile 
terminal. 

Next, TACAF and MCF of the mobile terminal send a START CIPHERING 
25 response confirmation to TACF and SACF of the network, this confirmation indicating 
that mobile station will next start to transmit enciphered signals. Consequently, the 
network entities can recognize that the succeeding signals transmitted from the 
mobile terminal will be ciphered. After the transmission of the START CIPHERING 
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response confirmation, TACAF and MCF of the mobile terminal cipher succeeding 
signals according to a preselected encipherment procedure using . a preselected 
ciphering key. Once the terminal entities receive the enciphered signal, TACF and 
SCF decipher the received signals. Accordingly, the uplink signal transmitted from 
5 the mobile terminal can be transported in secret and interpreted by only the network. 

Next, it will be discussed which kind of information should be ciphered. In 
the invented system, the source device can freely decide the information to be ciphered 
as long as the destination device is notified of the ciphered information and 
communications at layers 1 through 3 are established. 

10 It is known that open system interconnection protocols should be adapted to 

the open system interconnection reference model illustrated in Figure 263. The OSI 
model defines the hierarchy consisting of seven functional layers for managing various 
functions from physical interconnection to application. 

The lowest layer, layer 1 is called the physical layer. The physical layer 

15 prescribes mechanical or electrical procedures or means, for example, configurations of 
connection plugs. 

Layer 2, datalink layer operates to establish, maintain, and release an 
individual data link and to detect and recover the error occurring in the physical layer. 

Layer 3, network layer sets up and manages an end-to-end connection 
20 between different networks, whereby the upper layers can proceed their respective 
functions without processing for the network type. 

Layer 4, transport layer controls the transparent end-to-end data relaying 
service between session entities. 

Layer 5, session layer establishes or releases the session connection. 
25 The sixth or presentation layer negotiates agreeable technique for data 

encoding and punctuation. 

The seventh or application layer identifies the communicating source and 
instructs the service quality. 
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The international telecommunication union (ITU) scribes the line circuit 
interface at layer 3 that corresponds to layers 3 through 7 in the OSI reference model. 

The relationship of the OSI reference model and the present system will be 
described in more detail with reference to Figure 753. Figure 753 is a general view of 
5 the present system. 

The system illustrated in Figure 753 includes a mobile station MS, a plurality 
of radio base stations BS communicable with the mobile station MS over the air, an 
base station controller RNC for controlling the base stations BS, and a mobile service 
switching center MSC for connecting the base station controller RNC with a fixed 
10 network. In addition, the system meets the following conditions: 

i) Both of the mobile station MS and the base station controller RNC 
can carry out diversity reception and distribution. 

ii) Layer 1 of the OSI reference model for the radio channel supervises 
between the mobile station MS and the respective base stations BS. 

15 iii) Layer 2 of the OSI reference model for the radio channel supervises 

between the mobile station MS and the base station controller RNC. 

iv) Layer 3 of the OSI reference model for the system supervises between 
the mobile station MS and the base station controller RNC or between the mobile 
station MS and the mobile service switching center MSC. 

20 In addition, Layer 2 should meet the following functional conditions: 

i) At the source, it has a function to retransmit layer-2 frames 

ii) At the destination, it has a function to reassemble layer-3-frames 
from received layer-2-frames in the regular order even if a layer-3-frame was divided 
into a plurality of layer-2-frames at the source. 

25 iii) At the destination, it does not have a function to interpret a ciphered 

signal and non-ciphered signal both corresponding to the same information when it 
receives them simultaneously. 

Under the above-mentioned conditions, assume that layer 2 conducts the 
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encipherment procedure on layer 2. In this case, as shown in Figure 754, an 
application in the mobile service switching center MSC sends an encipherment onset 
indication at step SI. The encipherment onset indication is transferred from layer 3 
to a layer-2-controller at step S2, to a layer-2-cipherer/decipherer at step S3, and to the 
mobile station MS at step S4. 

The network application then sends an encipherment onset request to the 
layer-2-cipherer/decipherer of the mobile station MS via the layer-2- 
cipherer/decipherer of the network at step S5. Afterward, the application of the 
mobile service switching center MSC makes the layer-2-cipherer/decipherer of the base 
station controller RNC carry out the encipherment process, whereby the signal 
transmitted from the layer-2-cipherer/decipherer are enciphered. 

In the mobile station MS, the encipherment onset indication is transferred 
from layer-2-cipherer/decipherer to layer-2 -controller at step S6, to layer 3 at step S7, 
and finally to the application at step S8. Upon the reception of the encipherment 
onset indication, the application of the mobile station instructs or sets the layer-2- 
cipherer/decipherer to decipher the transmitted signal from the network at step S9. 

If the second layer conducts the encipherment process under the above- 
described conditions, the encipherment is started at the network before the signals are 
distributed to the radio base stations BS for diversity handover in the network. 
Therefore, the mobile stations can receives the ciphered signals from the respective 
base stations, thereby achieving diversity handover surely even if it cannot process in 
parallel an enciphered signal and non-enciphered signal. 

However, in this case, it is possible that the application of the mobile station 
requests the layer-2-cipherer/decipherer to decipher signals (Step S9) simultaneously 
with the retransmission request from the layer-2-controller in the mobile station to the 
network (Steps S 10 to S12). If the network begins to retransmit the requested signals 
(Steps S13 and S14) before the completion of the decipherment set-up in the layer-2- 
cipherer/decipherer, the layer-2 -cipherer/decipherer will not decipher the enciphered 
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signal and transfer it as it is to the layer-2-controller. In this case, the layer-2-frame 
sequence number of the signals may not be interpreted. This phenomenon is caused 
from that although layer 2 (datalink layer) detects errors occurring at layer 1 (physical 
layer) referring to CRCs attached to the signal frames and facilitates the 
retransmission, layer 2 also provides the encipherment procedures. 

This results in problems: the first problem is that the retransmitted layer-2 
frames cannot be utilized, and the second problem is that it is impossible to reassemble 
layer-3-frames from received layer-2-frames in the regular order if a layer-3-frame was 
divided into a plurality of layer-2-frames at the source. 

Accordingly, it is preferable that the mutual notification of the encipherment 
onset (transmission of START CIPHERING request indication and START 
CIPHERING response confirmation) is conducted at the layer which is layer 3 or 
higher rather than layer 2 in the OSI reference model. Therefore, in the system, 
ciphered is only information that should be processed only in one or more layers which 
are the same as or higher than layer 3 of the OSI reference model although the mutual 
notification of the encipherment onset time is conducted at layer 2. 

Consequently, although normal reception is not achieved by an error occurring 
in layer 1 (physical layer), the retransmission can be made out by the error detection 
and retransmission in layer 2 independently of layer 1. The retransmission causes 
the reception of the non-received signals in the proper order by the destination. 
Therefore, the destination can recognize the encipherment onset time at an improved 
precision. However, if the reliability of layers 1 and 2 can be improved, it is possible 
to cipher at layer 2. 

2.2.4 REASSIGNMENT OF TMUI 

In the system, an IMUI (international mobile user identity) is already 
assigned to each of the mobile stations. Each mobile station stores the corresponding 
IMUI while the network stores a plurality of IMUI of the mobile stations. 
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Communication may be carried out using the IMUIs, but they can be intercepted by a 
third party since mobile communications may be achieved by the air interface. This 
results in that the third party, can communicate using the intercepted IMUI. 

Therefore, in the present system, the network assigns another identity, 
5 namely, TMUI (temporary mobile user identity) to each of the mobile stations that is 
communicable with the network and notifies the corresponding mobile station about 
TMUI. More specifically, the TMUI is enciphered to be preserved from being 
intercepted, and then transmitted through the air interface to the mobile station. 

The assignment of TMUI is conducted at the location registration procedure. 

10 If the location registration procedure is failed, the location registration procedure 
should be repeated again. Therefore, confusion of TMUI at each mobile station will 
not occur in theory. However, if a machine storing TMUI in a mobile station or the 
network malfunctions, such confusion of TMUI and IMUI may occur. 

In this case, recovery process is needed for correcting the confusion. 

15 Therefore, the system adopts the following procedures, which should be carried out by 
the network and the mobile station MS. 

Figure 264 represents a sequential operation by the network and a mobile 
station MS. This operation starts after a call attempt comes into the network from a 
user terminal other than the mobile station MS illustrated in Figure 264. Once the 

20 network (more exactly, the mobile communications control center) receives a call 
income, the mobile communications control center first carries out a paging in a 
manner that TMUI of the incoming call destination is specified, as shown in Figure 
264. This paging process is a broadcasting of TMUI to the areas of which the mobile 
communications control center MCC is in charge. 

25 As mentioned above, TMUI is assigned to each mobile station MS 

communicable with the mobile communications control center MCC and each mobile 
station MS stores its TMUI. Therefore, once mobile stations MS receive the 
broadcast TMUI, each mobile station determines whether the broadcast TMUI is 
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coincident with the TMUI stored therein. If the determination is affirmative, only the 
corresponding mobile station MS sends a paging response to the mobile 
communications control center MCC at step S2. 

Next, the network checks the authenticity of the user (see section 2.3.2.4.1). 
More specifically, the network generates a necessary authentication information 
(random number) for checking the authenticity of the accessing mobile station MS and 
transmits it to the mobile station MS at step S3. Once the mobile station MS receives 
the authentication information, the mobile station MS executes an arithmetic 
operation based on the authentication information (random number) and transmits 
the authentication calculation result as an authentication response at step S4. The 
authentication calculation uses an authentication key stored in each mobile station 
MS previously. The network stores the authentication keys of the respective users at 
its storage device (e.g., SDF) in a manner that the respective authentication keys are 
associated with the respective IMUIs and TMUIs for finding the correlation. 

Then, the network reads out the authentication key corresponding to the 
temporary mobile user identity used for the paging at step SI. Next, the network 
executes the authentication calculation on the basis of the read authentication key and 
the authentication information (random number) transmitted at step S3, and 
determines whether or not this calculation result is coincident with the calculation 
result by the mobile station MS at step S5. If the determination is affirmative (the 
results are coincident), the mobile station MS is authenticated (the mobile station 
belongs to a proper subscriber and is the proper call destination). Afterward, a 
normal incoming call acceptance procedure is executed. 

However, if the determination is negative (the results are not coincident), the 
mobile station MS is not the call destination. Such a discord is caused from that the 
replying mobile station MS is fraudfull or TMUI managed by the network and TMUI 
managed by the proper subscriber's mobile station became discord with each other 
accidentally. Accordingly, the network checks the authenticity of the mobile station 
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using the international mobile user identity. 

Specifically, first the network (in fact, the mobile communications control 
center) transmits an IMUI transmission request to the mobile station MS for 
instructing it to transmit the IMUI at step S6. In response, the mobile station MS 
5 notifies the IMUI stored in itself. 

The network then generates the random number again as the authentication 
information and sends it to the mobile station MS. In response, the mobile station 
MS uses the authentication information and the authentication key stored in itself to 
execute an authentication calculation and sends the authentication calculation result 

10 as an authentication response to the network at step S9. 

The network then accesses to the storage device thereof and reads out the 
authentication key corresponding to the IMUI obtained at step S7. Next, the network 
executes the authentication calculation on the basis of the read authentication key and 
the authentication information (random number) transmitted at step S8, and 

15 determines if this calculation result is coincident with the calculation result by the 
mobile station MS or not at step S10. If the determination at step S10 is negative 
(the results are not coincident), the mobile station MS is completely fraudfull, so that 
the radio channel between the network and the mobile station MS is disengaged, 
thereby finishing the communication at step S12. 

20 On the contrary, if the determination at step S10 is affirmative (the results are 

coincident), the mobile station MS can be considered to belong to a proper subscriber, 
but its TMUI was altered accidentally. Thus, the mobile communications control 
center MCC reassigns TMUI at step Sll. In other words, as long as the mobile 
station MS belongs to a proper subscriber, it can obtain TMUI again and afterward it 

25 can communicates with the network by means of the newly assigned TMUI although 
the former TMUI has been changed to null accidentally. However, since the mobile 
station is not a call destination in fact (although the mobile station belongs to a proper 
subscriber), the . radio channel between the network and the mobile station is 
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disconnected, so that the communication is ended at step S12. 

As described above, according to this reassignment of TMUI, although TMUI 
stored in the network and TMUI stored in the mobile station MS is different, the 
network can recognize that mobile station MS belongs to a proper subscriber as long as 
the IMUI is correct and can reassign the new TMUI to the mobile station MS. 
Therefore, although the former TMUI has been changed to null accidentally, the 
mobile station can be returned quickly to the normal condition in which it can 
communicate normally. 

Furthermore, when the location of the mobile station is registered or the 
mobile station request the call origination as well as the incoming call acceptance 
described above, the authentication using the TMUI is conducted. In this case, the 
reassignment of the TMUI is conducted if necessary. In the network, the TMUIs are 
managed by SDF, which will be described later. SDF can be, for example, arranged in 
a location register for managing various information on subscribers in the network. 

2.3 BRIEF DESCRIPTION OF SYSTEM 

Next, the system will be described briefly. 



This system can totally provide various information transfers including voice 
transfer and data transfer. This system can also provide one mobile station with a 
plurality of bearer services at the same time. For example, the single mobile station 
can benefit by two unrestricted digital bearer services at 64 kbps simultaneously. 
Furthermore, unlike the traditionally PDC mobile communications system, the wire 
communication meets the requirements of ATM and the radio communication meets 
the requirements of CDMA, whereby transfer is achieved at improved quality and 
improved velocity. 

Figure 266 shows the features of services, which can be provided by this 



2.3.1 



PROVIDED SERVICES 
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system. In addition, the present system can be connected with another system 
managed in accordance with PSTN, N-ISDN, PLML, B-ISDN, or IMT-2000. 



This system can provide the following bearer services. 

(1) Circuit Switching Mode 

a) Voice Bearer Service at 8 kbps 

This bearer service is provided for supporting voice services. The digital 
signals at the Um reference point comply with ITU-T recommendation G.729. 
However, the bit transparency is not ensured. This bearer service will not be utilized 
for voice-band data communication. The features of the voice bearer service at 8 kbps 
are listed in Figure 267. 

b) Unrestricted Bearer Service at 64 kbps 

This bearer service provides information transfer at 64 kbps, the information 
being not changed between the Um reference points. The features of the unrestricted 
bearer service at 64 kbps are listed in Figure 268. 

c) Multiplex-Rate unrestricted Bearer Service at n X 64 kbps (n is a natural 
number, e.g., 6) 

This bearer service provides information transfer at 384 kbps wherein subrate 
information is multiplexed with one another, the subrate information being not 
changed between the Um reference points. The features of the multiple-rate 
unrestricted bearer service are listed in Figure 269. 

(2) PACKET SWITCHING MODE (should be studied further) 

This system can provide bearer services at the packet switching mode in 
addition to those at the circuit switching mode. 



2.3.1.1 



BEARER SERVICES 



2.3.1.2 MOBILITY SERVICE 

In order to facilitate the mobility or portability services, international mobile 
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user identity (IMUI) is adopted. IMUI is previously assigned to each of the mobile 
stations for identifying the respective mobile stations. Each mobile station stores its 
IMUI while the network mobile communications control center MCC stores a plurality 
of IMUIs of the mobile stations that are served by the network. When one mobile 
station moves to a next radio zone, the IMUI of the mobile station is utilized for the 
location registration and handover, so as to enable the mobile station to communicate 
irrespectively of its location. 

2.3.1.3 QUALITY REQUIREMENTS 

This system enables error correction coding and retransmission functions. 
Therefore, the average bit-error rate in the network and the air interface is ensured to 
be less than 10 3 in relation to voice transfer. In relation to transfer of information, 
e.g., data or control information other than voice, the average bit-error rate is ensured 
to be less than 10 6 . 

2.3.2 SYSTEM CAPABILITIES 

2.3.2.1 SYSTEM CAPABILITIES ON CONNECTION SERVICES 

2.3.2.1.1 ORIGINATION 

"Origination" is a series of controlling procedures for setting up the intra- 
network and network -MS access links necessary for communicating with a called 
terminal and for setting up connection to the called terminal on the basis of an access 
of a calling mobile station upon a call attempt by the user of the calling mobile station. 
"Origination" procedures include an SDCCH control, user identity retrieval, user 
authentication, encipherment-onset time notification, establishment of access link, 
mutual information transfer to and from the calling user terminal, and analysis. 

The system comprises the following capabilities for the origination procedures. 
First, it is possible to establish an SDCCH (stand-alone dedicated control channel) to 
inform the network of the call attempt by the mobile station MS. SDCCH will be 



F0220/2551 

111 

described later in more detail at the section entitled "SDCCH Control" of this chapter. 
Furthermore, in order to establish the association (terminal association) between the 
mobile station and the network, the system comprises the following functions. 

a) The network is notified of the call attempt indicating the temporary mobile 
5 user identity (TMUI) of a calling mobile station by the mobile station, thereby setting 
up the terminal association. In addition, the network is informed of feature 
capabilities of the mobile station by the mobile station and the information on the 
capabilities is stored in the network, so that the network controls to allow or reject the 
another call attempt to the mobile station. 

10 b) The network recognizes the calling mobile station, which has requested the 
call attempt, and transfers unique information about the calling mobile station from a 
network data base to analyzing functional entities and control functional entities. If 
the network cannot recognize the temporary mobile user identity (TMUI) the calling 
mobile station, the network sends an inquiry about the international mobile user 

15 identity (IMUI) to the calling mobile station for recognition. 

c) The user authentication of the. mobile station is executed as described above. 
The user authentication will be described in more detail at the section entitled "User 
Authentication" of this chapter. 

d) In order to preserve signals transmitted through the control channel and the 
20 information channel between the mobile station and the network from being 

intercepted and manipulated by a third party, signals are ciphered. The 
encipherment will be described in more detail at the section entitled "Encipherment" of 
this chapter. 

e) The mobile station is informed of successes and failures of the above- 
25 mentioned respective procedures. 

In addition, the network is informed of the services required by the calling 
mobile station after the establishment of the terminal association. In addition, the 
network informs the calling mobile station of the acceptance of the call attempt after 
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the establishment of the terminal association. 

Additionally, a call origination control function is informed of an instance of 
the terminal association control function, whereby they are associating with each 
other. 

5 The mobile station informs the network of the environmental radio condition 

around the mobile station when the calling mobile station sends the call attempt, 
whereby the network recognizes the condition. 

Upon the reception of the call attempt from the mobile station, the user profile 
of the originating terminal is retrieved and analyzed, so that the services that can be 
10 provided for the originating terminal are determined. 

On the basis of the analysis of on the call attempt from the mobile station, 
appropriate network resources, for instance, voice coder-decoders, data trunks, and 
wired channels in the network are captured, set up, and activated. 

The access link for the traffic channel and the associated control channel, 
15 which are suitable for the services requested by the calling mobile station, can be 
established (refer to the section entitled "Access Link Establishment" in this chapter). 
Once the associated control channel is established, the SDCCH transferring previously 
the control signals is released. The release of the SDCCH will be described in more 
detail at the section entitled "SDCCH Control" in this chapter. 
20 The called user terminal is requested to communicate with the originating 

user terminal. While the called terminal is requested to communicate, the 
originating user terminal is informed of the calling to the called user terminal and the 
response from the called user terminal. 

The calling or called mobile terminal, for which the call has been established, 
25 can originate another call (additional call). However, since the mobile terminal has 
been already authenticated, the authentication process is not carried out for the 
additional call. 

In addition, although a call has been established between terminals, another 
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call requested from a third party may be established. 

2.3.2.1.2 INCOMING CALL ACCEPTANCE 

"Incoming call acceptance" is a series of controlling procedures wherein the 
5 networks calls a destination user mobile station upon a service request from a calling 
user terminal, and receives the response from the destination user mobile station so 
that access-links within the network and between the network and the mobile station 
are established, and connection between those mobile stations are established for the 
communication between the calling and destination user terminals. "Incoming call 
10 acceptance" procedures include paging, SDCCH control, user identity retrieval, user 
authentication, encipherment-onset time notification, routing in the network, 
establishment of access link, mutual information transfer to and from the called user 
terminal, and analysis. 

The system comprises the following capabilities for the termination 
15 procedures. 

First, the network receives a call attempt from a calling user terminal which 
may be a subscriber terminal of this system or another system connected thereto. 
Then, the network retrieves the profile of the called user terminal on the basis of the 
mobile user identity of the called user terminal. Therefore, the network can obtain 

20 various information necessary for analyzing the services which can be provided for the 
called user terminal, for analyzing the condition of the called user terminal, for 
determining if paging is necessary or not, for determining the areas for the paging, and 
for establishing the terminal association between the network and the called user 
terminal. Then, the paging function entity of the network is activated for paging. 

25 However, the paging is not carried out for the additional call. 

The called mobile station is called by means of the mobile user identity of this 
mobile station. The network can recognize the responding mobile station. Usually, 
in this procedure, TUMI may be used for the mobile user identity. If the network 
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detects an abnormality of the TMUI, the IMUI uniquely given to the mobile station is 
used. The paging procedure may be realized by the following capabilities. 

a) The network recognizes the area or areas where the called mobile station is 
paged, and then determines the paging channels used for the paging. Then, the 
network distributes a paging signal to intra-network nodes (base terminal systems). 
In response, each BTS transmits a paging signal in its coverage sector for paging the 
called mobile station within the necessary area. 

b) An SDCCH is established in order that the mobile station sends the network a 
response to the paging. This feature will be described in more detail at the section 
entitled "SDCCH" control in this chapter. 

c) Once the called mobile station sends the network the response to the paging, 
the terminal association between the called mobile station and the network is 
activated. In addition, the response signal can be identified by a paging ID 
corresponding to the calling signal. Furthermore, the mobile station notifies the 
network about the capability of the mobile station. The network stores the 
information on the mobile station capability for future reception management of 
another new call attempt to the mobile station. 

The mobile station informs the network of the environmental radio condition 
around the mobile station when the mobile station responds to the paging, whereby 
the network recognizes the condition. 

Once the mobile station responds to the paging, the network establishes the 
terminal association between the network and the mobile station. The establishment 
of the terminal association is executed as follows: 

a) The user authentication of the mobile station is executed as described above. 
The user authentication will be described in more detail at the section entitled "User 
Authentication" of this chapter. 

b) In order to preserve signals transmitted through the control channel and the 
information channel between the mobile station and the network from being 



F0220/2551 




115 

intercepted and manipulated by a third party, signals are ciphered. The 
encipherment will be described in more detail at the section entitled "Encipherment" of 
this chapter. 

c) The mobile station is informed of successes and failures of the above- 
5 mentioned respective procedures. 

After the establishment of the terminal association, a routing process is 
carried out for specifying the route to the intra-network control node which has 
controlled the establishment, and then the intra-network control node is informed of 
the setting up of the channels within the network and the services requested by the 
10 originating user terminal, so as to activated the incoming call acceptance control 
function. Additionally, the incoming call acceptance control function is informed of an 
instance of the terminal association control function, whereby they are associating 
with each other. 

Upon the call attempt, the user profile of the called terminal is retrieved and 
15 analyzed, so that the services that can be provided for the called terminal are 
determined. 

On the basis of the analysis of on the call attempt, appropriate network 
resources, for instance, voice coder-decoders, data trunks, and wired channels in the 
network are captured, activated and set up. 

20 The access link for the traffic channel and the associated control channel, 

which are suitable for the call attempt, can be established as will be described at the 
section entitled "Access Link Establishment" in this chapter. Once the associated 
control channel is established, the SDCCH transferring previously the control signals 
is released. The release of the SDCCH will be described in more detail at the section 

25 entitled "SDCCH Control" in this chapter. 

The called user terminal is informed of a service request from the originating 
user terminal. While the called terminal is informed of the service request, the 
originating user terminal is informed of the calling to the called user terminal and the 
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response from the called user terminal. 

Although a call has been established between terminals, another call 
requested from a third party may be established. 

In addition, the calling or called mobile terminal, for which the call has been 
established, can respond to another call (additional call). However, since the mobile 
terminal has been already authenticated, the authentication process is not carried out 
for the additional call. 

Furthermore, if a plurality of mobile stations respond to the incoming call 
acceptance paging, a new TMUI is, during the termination procedures, reassigned to 
one of the mobile station where the stored TMUI is changed accidentally. 



"Call release" is a series of procedures for releasing the link within the 
network and the access link between the mobile terminal and the network used for a 
call, and releasing the connection between the mobile terminal and the other user 
terminal. The call release is carried out upon a call release request from the mobile 
terminal or the other user terminal, or upon a detection of the deterioration of the 
radio communication quality. The call release includes a user disconnection 
procedure (updating the user status data) and a procedure for releasing access links. 

When releasing the last call for a mobile station, the association between the 
mobile station and the network is released. This process accompanies with updating 
the status data in connection with the mobile station. 

For executing the call release, the system comprises the following capabilities. 

The network is notified of a call release request from a user terminal, and the 
user terminal is notified of the acceptance of the release request by the network. 

In addition, the network informs the user terminal of a call release request 
from the other user terminal. 



In order to update the user status data when the call release occurs, the user 
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profile is updated. 

The access link corresponding to the released call is also released as will be 
described in more detail at section 3.2.2.3 entitled "Access Link Release." 

It is determined as to if the released call is the last call for the mobile station 
5 or not. If it is the last call, the status data in connection with the mobile station 
managed in the network is updated to indicate none call status. 

Call can be also released upon an access link release procedure (refer to 
section 3.2.2.3 entitled "Access Link Release") resulting from the detection of out of 
synchronization. 

10 Call can be also released upon a call release request from the mobile terminal. 

Call can be also released if the originating mobile station abandons the call. 

2.3.2:2 SYSTEM CAPABILITIES ON ACCESS LINK CONTROL 

2.3.2.2.1 SDCCH CONTROL 

15 "SDCCH Control" includes a procedure for establishing an SDCCH (stand- 

alone dedicated control channel) for transporting control massages between the mobile 
station and the network and a wired access link for transporting the control messages 
within the network on the basis of an access of a mobile station; and a procedure for 
releasing the SDCCH and the wired access link within the network when they become 

20 not necessary. These procedures are carried out for every process, which needs the 
interaction between the mobile station and the network, e.g., the mobile station call 
origination process, the mobile station call termination process, and the mobile station 
location registration. 

In order to execute the SDCCH control, the system comprises the following 

25 functions. 

The mobile station executes a random access procedure over the RACH 
(random access channel) and requests the network to establish the SDCCH. In 
response, the network assigns radio resources (uplink and downlink codes) for the 
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SDCCH to the mobile station using a FACH (forward access channel). The 
relationship between the establishment request and the assigned the code resources 
are determined by a random number (personal identification or PID) contained in the 
request message transmitted by the mobile station. 
5 In addition, the network can select the radio resources (uplink and downlink 

short codes) for the SDCCH for each sector from the resources managing for the sector. 
Unique uplink and downlink long codes are used for each base station. In addition, 
the phase of long codes used for each sector in a cell is different from that used for the 
other sectors in the same cell. Thus, the mobile station obtains the current downlink 
10 long codes by a cell search process or broadcast information from a broadcasting 
channel BCCH1 and obtains the current uplink long codes by broadcast information 
from the broadcasting channel BCCH1. 

The network also establishes a wired access link for transferring the control 
messages within the network upon the establishment request for the SDCCH from the 
15 mobile station. 

It is possible to recognize information on the location of the mobile station 
when requesting to establish the wired access link within the network. 

It is possible to control the power for transmission through the RACH, FACH, 
and SDCCH. The control manner will be described.at section 2.3.2.2.6 in more detail. 
20 The network and mobile station can recognize that the status in which the 

SDCCH is unnecessary since, for instance, a process, e.g., the location registration 
which is not associated with call is ended or transited to the ACCH. Then, the 
network and mobile can release the SDCCH respectively. 

25 2.3.2.2.2 ACCESS LINK ESTABLISHMENT 

"Access link establishment' 1 is a series of procedures for setting up a traffic 
channel for transferring user information and control channels for transferring control 
information between the network and the mobile station that originates a call or is 
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called. These procedures include establishing wired access link in the network and 
radio access link between the network and the mobile station. 

In order to execute the access link establishment, the system comprises the 
following capabilities. 

The network determines information transfer capabilities and quality levels 
needed for the respective connection access links on the basis of a call/connection 
control request, and then allocates appropriate resources to the access links. 

The mobile station designates candidate sectors, for which the wired access 
links or radio access links should be established, on the basis of the measurements of 
the perch channels and the broadcast information from the network. Then, the 
mobile station informs the network of the candidate sectors. The call acceptance 
control procedure will be described in more detail at section 2.3.2.2.7. 

The network sets up the wired access link between the network and the 
respective candidate sectors. Each established wired access link includes the traffic 
channel for transferring user information and, if necessary, the control channel for 
transferring control signals. 

The network stores the uplink long codes for radio access links in a database 
within the network according to MS identifiers (TMUI/IMUI). The network retrieves 
the information from the database to set up an access link. 

The network selects radio resources for the radio access link in the specified 
sector and allocate them to the mobile station. The radio resource selection will be 
described in more detail at section 2.3.2.2.5. 

The mobile station transmits information to the network for determining the 
initial power for transmission through the downlink radio access link, the information 
being based on the measurements on the perch channel and including information on 
the power for transmitting through the perch channel and the signal-to-interference 
ratio about the signal received from the perch channel. 

The network determines the initial power for transmission through the 
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downlink radio access link upon the reception of the information from the mobile 
station. The control of the transmission power will be described in more detail at 
section 2.3.2.2.6. 

The base station controller receives information on the wired access links and 
5 the radio access links and is able to start diversity handover based on the information 
at the same time when the access links are established for the candidate base stations, 
and carries out diversity handover on the basis of the information on the candidate 
sectors. Handover procedures will be described in more detail at section 2.3.2.2.4. 

The mobile station informs the network of the respective phase differences 
10 upon a broadcast information (periodical broadcasts at the intervals of 20 msec), each 
phase difference being the difference between the uplink long code phase of the sector 
to which the SDCCH is established and the uplink long code phase of another 
candidate sector. 

The network synchronizes the uplink radio access links on the basis of the 
15 uplink long code phase difference information from the mobile station. 

2.3.2.2.3 ACCESS LINK RELEASE 

"Access link release" is a series of procedures for releasing all traffic channels 
for transferring user information between the network and the mobile station and all 
20 control channels for transferring control information therebetween. "Access link 
release" procedures include a procedure for releasing wired access links in the network 
and radio access links between the network and the mobile station. 

In order to execute the access link release procedures, the system comprises 
the following capabilities. 
25 Due to release of an individual connection or release of connections for a 

released call, the network releases the corresponding access link. The release of 
access link is requested from the network to the corresponding mobile station. 

If the network detects out-of-synchronization status in connection with all 
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handover branches involved in an access link and does not detect the synchronization 
status again for a certain time period counted by a squelch reservation timer, the 
network executes to release the access link. 

If the mobile station detects out-of-synchronization status in connection with 
5 all handover branches involved in an access link, the mobile station stops to transmit 
over radio channels involved in the access link and causes the network to recognize 
that the out-of-synchronization status occurs. It is possible that the mobile station 
informs the network of the occurrence of the out-of-synchronization. 

When an access link is released during diversity handover, all the handover 
10 branches involved in the access link are also released. 

2.3.2.2.4 HANDOVER 

"Handover" is a series of procedures for altering the access point through 

which a mobile station accesses the network while the communication therebetween is 
15 continued. The handover is necessary for the reason of travelling of the mobile 

station and deterioration of the communication quality, or in order to distribute traffic. 

The handover procedures include alteration of radio access link and if necessary, 

alteration of wired access link. In order to execute handover, the system comprises 

the following capabilities. 
20 The system can execute various types of processes for realizing handover as 

described below. 

a) INTER-SECTOR HANDOVER BRANCH ADDITION IN SINGLE CELL 
Near the boundary between sectors in a single cell, added is a branch for a 

new sector, which is different from the sector currently used, but in the same cell. 
25 This addition does not accompany with an addition of the wired access link in the 
network. 

b) INTER-CELL HANDOVER BRANCH ADDITION 

Near the boundary between cells, added is a branch for a new cell, which is 
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different from the cell used currently. This addition does accompany with an addition 
of the wired access link for the newly added cell in the network. 

c) INTER-SECTOR HANDOVER BRANCH DELETION IN SINGLE CELL 
Near the boundary between sectors in a single cell, deleted is one of handover 

5 branches for the sectors when intra-cell diversity is no longer necessary. This 
deletion does not accompany with a deletion of the wired access link in the network. 

d) INTRA-CELL HANDOVER BRANCH DELETION 

Near the boundary between cells, deleted is one of handover branches for the 
cells when inter-cell diversity is no longer necessary. This deletion does accompany 
10 with a deletion of the wired access link for the newly deleted cell in the network. 

e) INTRA-CELL BRANCH REPLACEMENT HANDOVER 

At a boundary between sectors in a single cell, all handover branches are 
released, and then a new access link is established for the sector, which should be 
newly served. If the service attributes are not necessary to be changed for this 
15 handover, the wired access link in the network is left. 

f) INTER-CELL BRANCH REPLACEMENT HANDOVER 

At a boundary between cells, all handover branches are released, and then a 
new access link is established for the cell, which should be newly served. If the 
service attributions are not necessary to be changed for this handover, the wired access 
20 link in the network is left. 

g) INTRA-SECTOR FREQUENCY REPLACEMENT HANDOVER 

For all handover branches being used for communication, the radio frequency 
is replaced by another frequency. This handover does not accompany with an 
addition or deletion of the wired access link in the network. 
25 h) CODE REPLACEMENT HANDOVER 

For a handover branch being used for communication, the downlink short code 
is replaced by annother downlink short code belonging to the same code type in the 
same sector. This handover does not accompany with a replacement of the wired 
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access link in the network. 

i) USER DATA RATE MODIFICATION 

In order to alter user-to-user connection attributions, e.g., the user data rate 
or voice/data type, all handover branches for the connection is released, and then 
5 access links for the altered connection are established, 
j) ACCH REPLACEMENT 

Although radio resources used by an ACCH are released for the reason that a 
connection or call is released, it is sometimes necessary to continue another call. In 
this case, the ACCH is handed over to the wired access link and radio access link that 
10 has been used for the remaining call. 

When control signals are transported through an ACCH corresponding to a 
connection, it is sometimes necessary to alter the transmission rate. In this case, the 
ACCH is handed over to the wired access link and radio access link that has been used 
for another connection. 
15 k) CODE TYPE REPLACEMENT 

"Code type replacement" may be carried out. In this case, for all handover 
branches being used for communication, the downlink short codes are replaced by 
downlink short codes belonging to a different code type in the same sector. This 
handover does not accompany with a replacement of the wired access link in the 
20 network. 

By the above-mentioned handover branch addition, the maximum number of 
handover branches availed for all simultaneous connections is "N." 

The mobile station, on the basis of the perch channel measurements and call 
acceptance information from the network, requests the network to activate the 
25 handover branch addition, handover branch deletion, and branch replacement 
handover. The request information for the activation includes the information for 
designating the candidate sectors for handover. The call acceptance control will be 
described in more detail at section 2.3.2.2.7. 
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Upon the reception of the activation request, the network selects the sectors 
for handover from the candidate sectors. 

In the handover branch addition, the network assigns the radio frequency 
band, which is the same as of the currently used branch, to the channel for the 
additional branch, the radio frequency band being the radio resource. In addition, the 
network assigns the same uplink code resources to all of the branches for one 
connection. The selection of the radio resources will be described in more detail at 
section 2.3.2.2.5. 

When it is impossible to carry out the handover because of a deficiency in 
necessary radio resources or intra-network resources, the network ignores the 
handover request from the mobile station. If the mobile station does not receive the 
handover executing instruction, from the network for a certain time, that should be 
transmitted upon the reception of the handover request from the same mobile station, 
the mobile station analyzes the necessity of handover again. Then, the mobile station 
requests the network to execute the handover again if it is determined to be necessary. 

The mobile station sends the network the information to be used for 
determining the initial transmission power over the downlink access link of the 
additional branch. The information is based on the perch channel measurements. 

Upon the reception of the information for determining the initial transmission 
power, the network determines initial transmission power over the downlink access 
link of the additional branch. The transmission power control will be described in 
more detail at section 2.3.2.2.6. 

In the handover branch addition, based on a broadcast information (periodical 
report information) at the intervals of 20 msec, the mobile station informs the network 
of the phase difference of uplink long codes among the respective candidate sectors, 
and the group of frame offsets and group of slot offsets used in the mobile station. 

Upon the reception of notification of the uplink long code phase difference 
information and the groups of frame offsets and slot offsets, the network establishes 
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the synchronization of the uplink radio access link of the sector corresponding to the 
added branch. 

At the same time for execution of the branch addition, intra-sector frequency 
replacement handover, or user data rate modification, it is possible to execute the 
handover branch addition at boundary between sectors in single cell or at the 
boundary between cells. By the handover branch addition at boundary between 
sectors in single cell or at the boundary between cells, the maximum number of newly 
added handover branches is'N - 1. 

The handover branch addition and handover branch deletion can be executed 
at the same time. After the execution of the handover branch addition and handover 
branch deletion in the combined manner, the maximum number of the branches is "N." 

At the same time for execution of the access link establishment, the handover 
branch addition, branch replacement handover for another connection, ACCH 
replacement, or the code type replacement may be executed for another connection. 

The network requests the mobile station to replace the short codes in order to 
utilize the short code resources efficiently. 

At the same time for the releasing access links, the ACCH replacement is also 
carried out. 

However, handover of the SDCCH is not carried out. 

2.3.2.2.5 RADIO RESOURCE SELECTION 

"Radio resource selection" is a selection of suitable radio resources, for 
instance, radio frequency channel, short codes, offsets, on the basis of information 
transmitted from the mobile station to executing the SDCCH establishment, access 
link establishment, and the procedures for handover. For the radio resource selection, 
the system comprises the following capabilities. 

The mobile station informs the network of the radio capabilities, for example, 
the available radio frequency channels or available spreading codes of the mobile 
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station. 



The network retrieves uplink long codes from a database in the network, the 
uplink long codes being associated with respective mobile stations, so that each mobile 
station corresponds to unique uplink long codes. 

The network manages the states of respective uplink short codes (if the uplink 
short codes are used by mobile stations or not) for each sector and selects the uplink 
short codes for respective connections. The network also determines to execute or 
refuse the requested radio resource selection on the basis of the respective uplink 
interference levels of the sectors, requested transmission rate, and requested quality 
level. 

The network manages the states of respective downlink short codes (the 
downlink short codes are used by the respective mobile station or not) and selects the 
downlink short codes for respective connections in accordance with a request. 

The network selects the group of radio frame offsets and group of slot offsets 
during the radio resource selection for the SDCCH establishment and access link 
establishment. 



"Transmission power control" includes an initial transmission power 
determination process for determining the initial transmission power for transmitting 
signals through the radio access link at the start of signal transmission through the 
RACH (random access channel) or the FACH (forward access channel), at the SDCCH 
(stand alone dedicated control channel) establishment, at access link establishment, or 
at procedures for handover; and a downlink transmission power control for respective 
handover branches during diversity handover. However, the transmission power 
control does not include the transmission power control executed at layer 1. 



2.3.2.2.6 



TRANSMISSION POWER CONTROL 



(1) INITIAL UPLINK TRANSMISSION POWER DETERMINATION 



F0220/2551 




127 

Power for transmission over the uplink radio channel from the mobile station 
to the base station should be minimized as small as possible to reduce the capacity of 
the uplink radio channel and to prevent other radio access links from affected. For 
this purpose, it is preferable to select the radio zone in which the power can be 
5 minimized for signal conveyance when selecting the radio zone whose base station 
should be ready (on standby) for communication with the mobile station immediately 
or will commence communication with the mobile station after handover. Therefore, 
means for the selection is necessary. 

However, traditional mobile stations simply detect respective reception levels 
10 or respective SIRs (signal-to-interference ratios) of channels for the base stations as 
information used for radio zone selection. Furthermore, the respective transmission 
power levels vary according to the base stations sometimes. Therefore, in traditional 
communications systems, it is impossible for each mobile station to optimize the 
uplink transmission power from the mobile station itself to the network. 
15 In order to resolve these issues and determine the initial uplink transmission 

power optimally, the system comprises the following capabilities. 

Using the periodical report (information broadcast at the intervals of 20 msec) 
via perch channels, the network broadcasts calibrated perch channel transmission 
power levels. The calibrated perch channel transmission power levels has been 
20 calibrated in view of the respective path losses at cables and so on within the 
respective base stations. 

Using the periodical report (information broadcast at the intervals of 20 msec) 
via perch channels, the network also broadcasts uplink interference levels. 

On the basis of the calibrated perch channel transmission power levels, the 
25 respective uplink interference levels, the respective perch channel reception power 
levels measured at the mobile station, and respective signal-to-interference ratios 
involved in reception at the respective near base stations, the mobile station can 
determine the initial uplink transmission power level. The signal-to-interference 
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ratios as reference data are previously stored in the mobile station. 

With reference to Figure 792, the initial uplink transmission power 
determination will be described below. 

In Figure 792, two base stations "A" and "B" transmits the broadcast 
5 information via the corresponding perch channels. The calibrated perch channel 
transmission power levels are Pa and Pb, respectively. The respective reception 
levels of the broadcast information at the mobile station via the perch channels from 
the base stations are Ra and Rb. The mobile station can calculate the respective path 
losses on the basis of the perch channel transmission power levels Pa and Pb indicated 
10 in the broadcast information and the respective perch channel reception levels Ra and 
Rb. More specifically, the path loss Lpa from the base station "A" to the mobile 
station is calculated by the next formula. 

Lpa = Pa - Ra 

The path loss Lpb may be calculated similarly. 

15 On the basis of the calculated respective path losses in relation to the base 

stations, the respective uplink interference levels in relation to the base stations, and 
respective signal-to-interference ratios involved in reception at the respective near 
base stations, the mobile station calculates respective necessary uplink transmission 
power levels between the mobile station and respective near base stations. This 

20 calculation is conducted for selecting the radio zone to which a mobile station should 
camp on or should be handed over. More specifically, the mobile station selects the 
radio zone in which the necessary uplink transmission power level is minimum among 
the respective necessary uplink transmission power levels, and optimizes (minimizes) 
the uplink transmission power in accordance with the selected radio zone (selected 

25 base station). Accordingly, although the respective transmission power levels of the 
perch channels vary according to the base stations, each mobile station can optimize 
the uplink transmission power in the invented system. 
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(2) INITIAL DOWNLINK TRANSMISSION POWER DETERMINATION 

1) FACH AND DOWNLINK SDCCH 

The mobile station sends information via RACH to inform the network (more 
exactly, BTS) of the signal-to-interference ratio in relation to the perch channel 
reception at the mobile station. The BTS determines the initial downlink 
transmission power through the FACH (forward access channel) or SDCCH (stand 
alone dedicated control channel) on the basis of the perch channel signal-to- 
interference ratio in relation to the reception at the mobile station, the perch channel 
transmission power level, the required signal-to-interference ratio involved in 
reception at the mobile station via the FACH or SDCCH, and a rate-calibration 
parameter. Thes perch channel transmission power level is stored as a reference data 
for the BTS. 

2) DOWNLINK TCH 

Using a broadcast channel (BCCH1) mapped at the perch channel, the 
network (more exactly, BTS) broadcasts a perch channel transmission power levels, 
which is not calibrated. Using the SDCCH, the mobile station informs the network 
(more specifically, the base station controller function) of the perch channel reception 
SIR at the mobile station. Using the SDCCH, the mobile station informs the network 
(the base station controller function) of the perch channel transmission power level 
which is not calibrated. 

On the basis of the perch channel signal-to-interference ratio in relation to the 
reception at the mobile station, the non-calibrated perch channel transmission power 
level, the required signal-to-interference ratio involved in reception at the mobile 
station via the TCH (traffic channel), and a rate-calibration parameter, the BSC 
function in the network calculates the initial downlink transmission power through 
the TCH. The required SIR involved in reception at the mobile station via the TCH is 
stored as a reference data for the BSC function. If there are a plurality of candidate 
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zones from which selected is the zone to which the traffic channel is established, the 
BSC function calculates the respective initial downlink transmission power levels of 
the respective zones and selects the minimal power level. The branch for the zone 
corresponding to the minimal power level is the main branch. 
5 The BSC function of the network informs the base station of the initial 

downlink transmission power level. 

The mobile station can execute the low-rate downlink transmission power 
control according to layer 3 since it is possible that high-rate transmission power 
control is not executed ordinarily due to the deterioration of transportation via a radio 
10 branch during diversity handover. 

The mobile station informs the BSC function in the network of the non- 
calibrated perch channel transmission power level and the perch channel reception 
SIR periodically. 

The mobile station increases or decreases the SIR involved in the reception at 
15 mobile station, so that the reception quality at the mobile station maintains a 
standard quality. 

On the basis of the updated values, the network calculates and/or determines 
the transmission power level again. 

20 2.3.2.2.7 CALL ACCEPTANCE CONTROL 

"Call acceptance control" is a series of control procedures wherein the uplink 
interference level, downlink transmission power, and activated equipment resources, 
which can be measured or detected by the base station, are compared with respective 
allowable limits; a leeway/restriction (idle/busy) information is produced on the basis 

25 of the comparison; and a call attempt is allowed or restricted on the basis of the 
leeway/restriction information at a call origination, incoming call acceptance, bearer 
alteration, or handover. The call acceptance control can be conducted at the network 
and the mobile station. 
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However, the call acceptance control at the mobile station is an option. If the 
call acceptance control is conducted at the mobile station, it is possible to reduce the 
number of wastable call attempts, establishment attempts of traffic channels, bearer 
alteration requests, and handover requests. Therefore, the load involved in control 
5 procedures in the network can be lessened. 

On the other hand, the call acceptance control at the network is inevitable 
since the network should recognize the number of call acceptances and the congestion 
status of traffic. 

(1) CALL ACCEPTANCE CONTROL AT MOBILE STATION 

10 In order that the mobile station carries out the call acceptance control, the 

system comprises the following capabilities. 

Using broadcasting channels (BCCH2), the network broadcasts a call 
acceptance information. 

The mobile station refers to the broadcast information, via broadcasting 

15 channels BCCH2 from candidate base stations from which selected is the base station 
to which the traffic channel should be established, directly before the commencement 
of the random access for the first call origination, transmission of the setup message 
for the second call origination, reception ofthe setup message for call termination, 
handover trigger transmission, and transmission of the setup message to alter the 

20 bearer. 

On the basis ofthe call acceptance information, the mobile station determines 
to allow or reject the call attempt. 

(2) CALL ACCEPTANCE CONTROL AT NETWORK 

25 Upon the reception of a request for activating TCH, the network determines to 

allow or reject the call attempt on the basis of the call acceptance information. 



2.3.2.2.8 



STANDBY CONTROL 
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"Standby control" is controlling to transit the state, so that the mobile station 
can transmit and receive after the power of mobile station is turned on or after the 
mobile station visits from outside to inside of the network. Additionally, a procedure 
for changing the radio zone to camp on due to the travel of the mobile station is called 
5 "standby zone transition control." 

(1) STANDBY CONTROL 

In order to execute the standby control, the system comprises the following 
capabilities. 

10 Using the periodical report (information broadcast at the intervals of 20 msec) 

via perch channels, the network broadcasts the calibrated perch channel transmission 
power levels. The calibrated perch channel transmission power levels are calibrated 
in view of the respective path losses at cables and so on within the respective base 
stations. 

15 Referring to the calibrated perch channel transmission power levels in 

relation to the zones in which the downlink long codes may be used and the perch 
channel reception power levels at the mobile station, the mobile station selects the 
zone having the minimum path loss. Then, the mobile station refers to the broadcast 
information via BCCH1 corresponding to the selected zone. 

20 Using a broadcast channel (BCCH1) mapped at the perch channel, the 

network broadcasts a standby permission level, standby deterioration level, network 
number, restricted information, and so on. 

Referring to the broadcast information via BCCH1, the mobile station 
determines to allow or reject the standby. 

25 The network, using the broadcast information via BCCH1 at the perch 

channel, broadcasts the information on the data format in the control channel. 

Referring to the broadcast information via BCCH1, the mobile station 
determines the paging channel to which the mobile station is connected. 
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Referring to the broadcast information via BCCH1, the mobile station 
determines the RACH, which the mobile station should use. 

The network, using the broadcast information via BCCH1 at the perch 
channel, broadcasts the information on the uplink long codes for the corresponding 
5 zone. 

Referring to the broadcast information via BCCH1, the mobile station 
determines the uplink long codes used for the RACH and SDCCH. 

(2) STANDBY ZONE TRANSITION CONTROL 

In order to execute the standby zone transition control, the system comprises 
the following capabilities. 

The network, using the broadcast information via BCCH1 at the perch 
channel, broadcasts information on the downlink long codes for the circumferential 
zones. 

The mobile station retrieves the information on the downlink long codes for 
the circumferential zones from the broadcast information via BCCH1, and conducts 
the zone transition. 

2.3.2.3 SYSTEM CAPABILITIES ON MOBILITY MANAGEMENT 

20 Next, system capabilities on mobility management will be described. 

2.3.2.3.1 TERMINAL LOCATION REGISTRATION AND UPDATE 

For permitting the travel of the mobile terminals, the terminal locations are 
supervised by the network. Therefore, the terminal location data is registered when a 
25 user terminal is first detected by the network (when the power of the mobile terminal 
is turned on or the user terminal roams to the network from another network). The 
terminal location data is automatically updated when the location of a mobile terminal 
changes in the same network. 



F0220/2551 





F0220/2551 




134 

In order to execute the terminal location registration and update, the system 
comprises the following capabilities. 

The network informs a mobile station of the location information, so that the 
mobile stations recognize the location information. 

When the mobile station travels in the network, the network recognizes that 
the mobile station moves from the location that is managed by the network and 
requests to update the location information managed in the mobile station. 

An SDCCH (stand alone dedicated control channel) is established for 
transporting the control signals for the location registration between the network and 
the mobile station (refer to the section entitled "SDCCH Control"). 

Terminal authentication is carried out to prevent the network from an access 
by an improper mobile terminal. Insofar as a terminal is authenticated, the location 
information on the terminal is updated in the network. 

The network can assign a new TMUI (temporary mobile user identity) to a 
mobile station. 

The network starts the authentication with the IMUI of a mobile station if the 
mobile station is not authenticated by the TMUI check. 

The network notifies the mobile station of the location registration completion. 

If the mobile station does not receive the location registration/update 
completion report, the mobile station triggers the location registration/update 
procedure again. 

2.3.2.4 SYSTEM CAPABILITIES ON SECURITY SERVICES 

Next, system capabilities on security services will be described. 

2.3.2.4.1 USER AUTHENTICATION 

"User authentication" is to determine if each mobile user terminal sending a 
call attempt to the network is proper or not. The user authentication is carried out 



F0220/2551 




135 

when a mobile station originates a first call, when a first call is directed to a mobile 
station, or when the location is registered. 

In order to execute the user authentication, the system comprises the 
following capabilities. 

5 When a mobile station accesses the network, the network produces various 

information (an authentication calculation result and random number) being 
necessary for the authentication of the mobile station, and requests the mobile station 
to execute an authentication calculation. The network produces an encipherment key 
used in an encipherment calculation after the authentication. 
10 The mobile station produces an authentication calculation result based on the 

random number sent by the network and informs the network of the result. 

The authentication calculation results made by the network and the mobile 
station are compared with each other. 

The network sends an inquiry about the international mobile user identity 
15 (IMUI) to the mobile station if the mobile station has not been authenticated at the 
authentication procedure using the temporary mobile user identity (TMUI). The 
network then produces the authentication information and executes the 
authentication procedure using the IMUI. 

If the mobile station is not authenticated even at the authentication procedure 
20 using the information based on the IMUI, the origination procedure, the termination 
procedure, or location registration procedure is stopped. 

2.3.2.4.2 ENCIPHERMENT 

"Encipherment" is a series of procedures to cipher control signals or user 
25 signals transported through the SDCCH, ACCH, or TCH for preventing the signals 
from being intercepted or edited by a third party. The encipherment is carried out at 
the origination procedure, the termination procedure, or location registration 
procedure. 
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In order to execute the encipherment, various information, e.g., encipherment 
keys and relevant information for producing the encipherment keys, for ciphering or 
deciphering control signals or user signals thait should be transported via wireless 
interfaces are managed. The information is delivered within the network and to the 
destination mobile station when the encipherment is conducted. 

The delivered information is used for ciphering the signals and the ciphered 
signals are transported via radio interfaces. 

The onset time of ciphering and onset time of deciphering are mutually 
notified between the network and the mobile station. 

2.3.2.4.3 TMUI MANAGEMENT 

TMUI is a temporary terminal identifier or user identifier transported via the 
air interface in order to keep the IMUI a secret and to decrease the total length of the 
terminal identifier. The network assigns the TMUIs to the mobile stations 
communicable with the network and informs the respective mobile stations of the 
individual TMUIs. After the TMUI assignment, the network manages each TMUI all 
the while the corresponding mobile station exists in the coverage area of the network. 
The TMUI assignment may be executed at the location registration procedure, 
origination procedure, and termination procedure. However, in the invented system, 
the assignments of TMUIs at origination procedure and termination procedure are 
option. 

In order to execute the TMUI management, the system comprises the 
following capabilities. 

When the network accesses a mobile station for the location registration, 
location update, origination (option), or termination (option), the network prepares a 
TMUI for the mobile station and stores it. 

The network informs the mobile station of the TMUI and confirms that the 
mobile station stores the TMUI. When the location is registered, the mobile station is 
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informed of information indicating the TMUI and the node where the TMUI is 
assigned. However, at the origination or termination, the mobile station is informed 
of only the TMUI. 

The TMUI is sent from the network to the mobile station via the air interface 
after ciphering for preventing the TMUI being intercepted improperly at the air 
interface. 

In order to prevent double assignment of the TMUIs, the association of TMUIs 
and the mobile stations are managed. 

2.3.2.5 SYSTEM CAPABILITIES ON SYSTEM MANAGEMENT 

Next, system capabilities on system management will be described. 

2.3.2.5.1 REQUIREMENT FOR SYSTEM SYNCHRONIZATION 

"Requirement for system synchronization" is a requirement for 
synchronization in the system including the network and a mobile station in order to 
perform diversity handover with a minimum buffering delay. In this system, the 
MSC (MCC) and the serving BTSs operate according to the standard clock signal at 
the regular intervals of 640 msec, so that the time alignment is established among the 
MSC (MCC) and the serving BTSs. However, the phase difference among the MSC 
function and the serving BTSs is allowable insofar as it is equal to or less than 5 msec. 
In other words, the requirement for system synchronization is the phase difference 
within 5 msec. 

2.4 CONTROL MANNERS 

Next, control manners will be described. 



2.4. 1 FUNCTIONAL NETWORK ARCHITECTURE 

Figure 3 shows the functional network architecture of the system. The 
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functions of the functional entities comply with ITU-T Recommendations. 

In Figure 3, CCAF (call control agent function) in a mobile terminal is an 
interface between the user mobile terminal and CCF (call control function) of the 
network for providing access for users. TACAF (terminal access control agent 
function) in a mobile terminal controls access for the mobile terminal, e.g., terminal 
paging detection. 

BCAF (bearer control agent function) in the mobile terminal controls radio 
bearers for the mobile terminal. BCF (bearer control function) controls bearers. 
BCFr (bearer control function (radio bearer associated)) in the network controls radio 
bearers. 

TACF (terminal access control function) in the network controls access for the 
mobile terminal, e.g., terminal paging execution. CCF (call control function) controls 
call and connection. SCF (service control function) controls services. SDF (service 
data function) stores various data for execution of services. 

LRCF (location registration control function) controls the mobility 
management. LRDF (location registration data function) stores various data for 
mobility management. SSF (service switching function) is an interface between the 
CCF and SCF and detects the trigger for a service control. SRF (specialized resource 
function) controls access to a special device, e.g., information storing device. 

MCF (mobile control function) in the mobile terminal is an interface to the 
network for a non-call service. SACF (service access control function) in the network 
is an interface to the mobile station for a non-call service. MRRC in the mobile 
station controls radio resources. RRC in the network controls radio resources. 

MRTR (mobile radio transmission and reception) in the mobile station 
controls the encipherment or transmission and so on. RFTR (radio frequency 
transmission and reception) in the network controls the encipherment or transmission 
and so on. UIMF (user identification management function) stores the information 
on the mobile users and provides the user authentication and encipherment. In the 
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following description, the UIMF may be sometimes called UTMF. 

Figure 4 is a diagram showing the functional network architecture of the 
system, in which functional entities are arranged in a communication control plane 
and a radio resource control plane. In Figure 4, functional entity numbers (FE 
5 numbers) are attached to respective functional entities. The correlation between the 
FE numbers and the functional entities are also represented in Figure 270. 

In addition, relationships between functional entities are shown in Figure 4. 
The designations of the relationships are also stated in the following. 

The relationship between FE01 and FE06 (CCAF'-CCF') is called Relationship 

10 ra. 

The relationship between FE02 and FE05 (TACAF-TACF) is called 
Relationship rb. 

The relationship between FE07 and FE09 (LRCF-SSF) is called Relationship 

rc. 

15 The relationship between FE07 and FE08 (LRCF-LRDF) is called 

Relationship rd. 

The relationship between FE09 and FE10 (SSF-SRF) is called Relationship re. 
The relationship between FE07 and FE10 (LRCF-SRF) is called Relationship 

rf. 

20 The relationship between FE05 and FE07 (TACF-LRCF) is called Relationship 

The relationship between FE05 and FE12 (TACF-SACF) is called Relationship 

rh. 

The relationship between FE05 and FE06 (TAGF-CCF 1 ) is called Relationship 

25 ri. 

The relationship between FE05 and FE04 (TACF-BCF) is called Relationship 

rj. 

The relationship between FE05 and FE04a is called relationship rja. 
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The relationship between FE05 and FE04b is called relationship rjb. 

The relationship between FE07 and FE12 (LRCF-SACF) is called relationship 

rk. 

The relationship between FE11 and FE12 (MCF-SACF) is called relationship 

5 rl. 

The relationship between FE01 and FE02 (CCAF'-TACAF) is called 
relationship rm. 

The relationship between FE02 and FE03 (TACAF-BCAF) is called 
relationship rn. 

10 The relationship between FE13 and FE14 (MRRC-MRTR) is called 

relationship ro. 

The relationship between FE13 and FE15 (MRRC-RRC) is called relationship 

rp. 

The relationship between FE15 and FE1G (RRC-RFTR) is called relationship 

15 rq. 

The relationship between FE03 and FE04 (BCAF-BCF) is called relationship 

rr. 

The relationship between FE04 and FE06 (BCF-CCF) is called relationship rs. 
The relationship between FE05 and FE15 (TACF-RRC) is called relationship 

20 rt. 

The relationship between FE02 and FE13 (TACAF-MRRC) is called 
relationship ru. 

The relationship between FE02 and FE17 (TACAF-TIMF) is called 
relationship rv. 

25 The relationship between FE11 and FE17 (MCF-TIMF) is called relationship 

rw. 

The relationship between FE01 and FE18 (CCAF'-UIMF) is called 
relationship rx. 
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The relationship between FE11 and FE18 (MCF-UIMF) is called relationship 

ry. 

The relationship between FE04a and FE04b (BCFr-BCF) is called relationship 

r44. 

5 The relationship between FE06 and FE06 (CCF'-CCF 1 ) is called relationship 

r66. 

The relationship between FE07 and FE07 (LRCF-LRCF) is called relationship 

r77. 

The relationship between FE05 and FE05 (TACF-TACF) is called relationship 

10 r55. 

The relationship between FE08 and FE08 (LRDF-LRDF) is called relationship 

r88. 

The above-described relationships between the functional entities are also 
represented in Figure 271. 

15 

2.4.2 INFORMATION FLOWS OF USUAL COMMUNICATION 

SERVICES 

2.4.2.1 ORIGINATION FOR INITIAL CALL AND ADDITIONAL CALL 

a) FUNCTIONAL MODEL 

20 a-1) INITIAL OUTGOING CALL 

Figure 5 shows the functional model of a part of the invented system for 
describing the origination for initial call. Radio bearers are selected under the BCFr 
controlled by the same TACF that received a call setup request. According to the 
radio resource selection scenario, multiple FEs are selected. 
25 a-2) ADDITIONAL OUTGOING CALL 

Figure 6 shows the functional model of a part of the invented system for 
describing the origination for additional call. Radio bearers are selected under the 
BCFr controlled by the same TACF that received a call setup request. According to 
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the radio resource selection scenario, multiple FEs are selected. 

b) INFORMATION FLOWS 
b-1) INITIAL OUTGOING CALL 

Figures 7 and 8 form an information flow diagram showing the origination for 
initial call. 

b-2) ADDITIONAL OUTGOING CALL 

Figure 9 is an information flow diagram showing the origination for additional 

call. 

c) DEFINITIONS OF INFORMATION FLOWS, INFORMATION 
ELEMENTS, AND FUNCTIONAL ENTITY ACTIONS 

The information flow diagrams will be described supplementally in the 
following and information elements in the flow diagrams will be discussed and 
represented in tables. 

A TA SETUP request indication is used by CCAF in the case of a mobile 
terminal call origination to request to set up a mobile terminal access to the network 
and the connection between the CCAF and TACAF. Figure 272 represents the detail 
of the TA SETUP request indication. 

Another TA SETUP request indication is sent from TACAF to request the 
establishment of the terminal access, i.e., signaling connection between TACAF and 
TACF. Figure 273 represents the detail of the TA SETUP request indication. For 
the user ID in Figure 273, TMUI should be used to maintain confidentiality of IMUL 
In this case, TMUI assignment source ID should not be included in order to reduce 
data length. 

A TA SETUP PERMISSION request indication is issued by the TACF to 
inform to request the authorization of the mobile terminal access to the network. 
Figure 274 represents the detail of the TA SETUP PERMISSION request indication. 

A REVERSE LONG CODE RETRIEVAL request indication is used to retrieve 
a reverse (uplink) long code. Figure 275 represents the detail of the REVERSE 
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LONG CODE RETRIEVAL request indication. 

Another REVERSE LONG CODE RETRIEVAL request indication is used to 
retrieve the reverse long code. Figure 276 represents the detail of the REVERSE 
LONG CODE RETRIEVAL request indication. 
5 A REVERSE LONG CODE RETRIEVAL response confirmation is also used to 

retrieve the reverse long code. Figure 277 represents the detail of the REVERSE 
LONG CODE RETRIEVAL response confirmation. 

A TERMINAL STATUS UPDATE request indication is used to update the 
terminal status. Figure 278 represents the detail of the TERMINAL STATUS 
10 UPDATE request indication. 

A TERMINAL STATUS UPDATE response confirmation is a response to the 
request indication. Figure 279 represents the detail of the TERMINAL STATUS 
UPDATE response confirmation. 

An ADD-ROUTING INFORMATION request indication is sent to the LRDF to 
15 add a routing address to the subscriber's profile. This information flow is sent only 
when the authentic mobile terminal has been found and the above related information 
has been obtained. Figure 280 represents the detail of the ADD-ROUTING 
INFORMATION request indication. 

An ADD-ROUTING INFORMATION response confirmation is a response to 
20 the request indication. Figure 281 represents the detail of the ADD-ROUTING 
INFORMATION response confirmation. 

A TA SETUP PERMISSION response confirmation is issued by the LRCF to 
inform the TACF that the mobile terminal access to the network is authorized. 
Figure 282 represents the detail of the TA SETUP PERMISSION response 
25 confirmation. 

A REVERSE LONG CODE RETRIEVAL response confirmation is used to 
retrieve the reverse long code. Figure 283 represents the detail of the REVERSE 
LONG CODE RETRIEVAL response confirmation. 
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A TA SETUP response confirmation is used to notify that the mobile terminal 
access has been established. Figure 284 represents the detail of the TA SETUP 
response confirmation. 

Another TA SETUP response confirmation is used to confirm that the setup of 
5 the terminal access and the connection between the CCAF and TACAF have been 
completed. Figure 285 represents the detail of the TA SETUP response confirmation. 

A SETUP request indication is used to request the establishment of the 
connection. Figure 286 represents the detail of the SETUP request indication. 



10 reverse long code. Figure 287 represents the detail of the TACF INSTANCE ID 
INDICATIONquest indication. 

A CELL CONDITION MEASUREMENT request indication is used by MRRC 
to trigger measurement of cell selection information. This is a requesting information 
flow whose confirmation (CELL CONDITION MEASUREMENT response 
15 confirmation) provides the result of the measurement. Figure 288 represents the 
detail of the CELL CONDITION MEASUREMENT request indication. 

A CELL CONDITION MEASUREMENT response confirmation provides the 
result of the cell selection information measurement requested by the CELL 
CONDITION MEASUREMENT request indication. Figure 289 represents the detail 
20 of the CELL CONDITION MEASUREMENT response confirmation. 

A CELL CONDITION REPORT request indication is used by the mobile 
terminal to report the cell selection information. The information is used by the 
network to select radio channels. This information flow does not require any 
confirmation. Figure 290 represents the detail of the CELL CONDITION REPORT 
25 request indication. 

A CALL SETUP PERMISSION request indication is issued by the SSF to 
request the authorization of the calling user. Figure 291 represents the detail of the 
CALL SETUP PERMISSION request indication. 



A TACF INSTANCE ID INDICATIONquest indication is used to retrieve the 
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A USER PROFILE RETRIEVAL request indication is used to request the user 
profile to be retrieved. Figure 292 represents the detail of the USER PROFILE 
RETRIEVAL request indication. 

A USER PROFILE RETRIEVAL response confirmation is a response to the 
5 request indication. Figure 293 represents the detail of the USER PROFILE 
RETRIEVAL response confirmation. 

A CALL SETUP PERMISSION response confirmation is issued by the LRCF 
to inform the calling user is authorized. Figure 294 represents the detail of the CALL 
SETUP PERMISSION response confirmation. 
10 A SETUP request indication is used to request the establishment of a 

connection. Figure 295 represents the detail of the SETUP request indication. 

A PROCEEDING request indication optionally reports that the indicated 
connection set-up is valid and authorized and that further routing and progressing of 
the call is proceeding. This information flow does not require any confirmation. 
15 Figure 296 represents the detail of the PROCEEDING request indication. 

A MEASUREMENT CONDITION NOTIFICATION request indication is 
transmitted at relationship rt between the TACF and the RRC and is used by the 
network to indicate conditions, which the mobile terminal measures, and to report the 
cell selection information. When the mobile terminal is on an idle mode, the network 
20 indicates the MEASUREMENT CONDITION NOTIFICATION request indication 
periodically. When the mobile terminal is in communication, the network indicates 
the MEASUREMENT CONDITION NOTIFICATION request indication at the change 
of conditions. This information flow does not require any confirmation. Figure 297 
represents the detail of the MEASUREMENT CONDITION NOTIFICATION request 
25 indication. 

Another MEASUREMENT CONDITION NOTIFICATION request indication 
is transmitted at relationship rp between the MRRC and the RRC and is used by the 
network to indicate conditions, which the mobile terminal measures, and to report cell 
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selecting information. When the mobile terminal is on an idle mode, the network 
indicates the MEASUREMENT CONDITION NOTIFICATION request indication 
periodically. When the mobile terminal is in communication, the network indicates 
the MEASUREMENT CONDITION NOTIFICATION request indication at the change 
of conditions. This information flow does not require any confirmation. Figure 298 
represents the detail of the MEASUREMENT CONDITION NOTIFICATION request 
indication. 

A REPORT request indication, at relationship r66 between a CCF' and 
another CCF', is an information flow that is used to report status and/or other types of 
information transported within the network. The type of information (e.g. alerting, 
suspended, hold, and resume) may be indicated. This information flow does not 
require any confirmation. Figure 299 represents the detail of the REPORT request 
indication. 

Another REPORT request indication, at relationship ra between the CCAF' 
and the CCF, is an information flow that is used to report the status information 
and/or other types of information transported within the network. The type of 
information (e.g. alerting, suspended, hold, and resume) may be indicated. This 
information flow does not require any confirmation. Figure 300 represents the detail 
of the REPORT request indication. 

A SETUP response confirmation at relationship r66 is used to confirm that the 
connection has been estab fished. Figure 301 represents the detail of the SETUP 
response confirmation. 

Another SETUP response confirmation at relationship ra is used to confirm 
that the connection has been established. Figure 302 represents the detail of the 
SETUP response confirmation. 



2.4.2.2 
a) 



TERMINATION FOR INITIAL CALL AND ADDITIONAL CALL 
FUNCTIONAL MODEL 
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a-1) INITIAL INCOMING CALL 

Figure 10 shows the functional model of a part of the invented system for 
describing the termination for initial call. 

a-2) ADDITIONAL INCOMING CALL 

5 Figure 11 shows the functional model of a part of the invented system for 

describing the termination for additional call. 

b) INFORMATION FLOWS 

b - 1) INITIAL INCOMING CALL 

Figures 12 through 14 form an information flow diagram showing the 
10 termination for initial call. 

b-2) ADDITIONAL INCOMING CALL 

Figures 15 and 16 form an information flow diagram showing the termination 
for additional call. 

c) DEFINITIONS OF INFORMATION FLOWS, INFORMATION 
15 ELEMENTS, AND FUNCTIONAL ENTITY ACTIONS 

The information flow diagrams will be described supplementally in the 
following and information elements in the flow diagrams will be discussed and 
represented in tables. 

A SETUP request indication is used to report the establishment of a 
20 connection. The detail is represented in Figure 303. 

A ROUTING INFORMATION QUERY request indication is used to inquire 
the routing information. The detail is represented in Figure 304. Either called user 
number or roaming number may be used as an identifier of the called user. Roaming 
number is used in this example represented in Figure 304. 
25 A TERMINAL ID RETRIEVAL request indication is used to request the user 

profile to be retrieved. The detail is represented in Figure 305. The roaming 
number item in Figure 305 is used in this information flow to specify the user whose 
profile should be retrieved, instead of the called user ID. The selection item in Figure 
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305 specifies the data which should be retrieved. This information element in this 
information flow specifies the user ID. 

A TERMINAL ID RETRIEVAL response confirmation is a response to the 
TERMINAL ID RETRIEVAL request indication. The detail is represented in Figure 
5 306. 

A TERMINAL STATUS QUERY request indication is used to inquire the 
terminal status (e.g. if terminal access is active or not). The detail is represented in 
Figure 307. The selection item in Figure 307 specifies the data which should be 
retrieved. This information element in this information flow specifies the user's call 
10 status. 

A TERMINAL STATUS QUERY response confirmation is a response to the 
TERMINAL STATUS QUERY request indication. The detail is represented in Figure 
308. 

A TERMINAL STATUS UPDATE request indication is used to update the 
15 terminal status. The detail is represented in Figure 309. 

A TERMINAL STATUS UPDATE response confirmation is a response to the 
TERMINAL STATUS UPDATE request indication. The detail is represented in 
Figure 310. 

A PAGING AREA QUERY request indication is used to inquire the paging 
20 area where TACF resides when it is observed that the terminal access is not active. 
The detail is represented in Figure 31L The selection item represented in Figure 311 
specifies the data which should be retrieved. This information element in this 
information flow specifies the paging area. 

A PAGING AREA QUERY response confirmation is a response to the PAGING 
25 AREA QUERY request indication. The detail is shown in Figure 312. 

A PAGE request indication at relationship rg is used to trigger a TACF of 
paging. The detail of the PAGE request indication is represented in Figure 313. 
Paging relationship ID in Figure 313 is generated by the LRCF and is used to correlate 
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the request and the response. 

A PAGING request indication at relationship rb is used to page a mobile 
terminal for determining its position in the network and for the routing for a call. 
This information flow requires a confirmation. The detail of the PAGING request 
5 indication is represented in Figure 314. The paging ID in Figure 314 is generated by 
the TACF and used to identify the response. 

A PAGING response confirmation is used to respond to the request indication. 
The detail is represented in Figure 315. 

A PAGE response confirmation is a response to the request indication and 
10 notifies the LRCF* of the paging result. LRCF initiates SLP for the user 
authentication of the responding user after receiving this information flow. The 
detail is represented in Figure 316. This information flow is also used in case of no 
response wherein if the optional information elements in Figure 316 are not read out, 
it is regarded that the paging request by the network is not responded by any 
15 terminals. 

A REVERSE LONG CODE RETRIEVAL request indication is used to retrieve 
a reverse (uplink) long code. The detail of the reverse long code at relationship rg is 
represented in Figure 317. 

Another REVERSE LONG CODE RETRIEVAL request indication is used to 
20 retrieve the reverse long code. The detail of the reverse long code at relationship rd is 
represented in Figure 318. 

A REVERSE LONG CODE RETRIEVAL response confirmation is used to 
retrieve the reverse long code. The detail is represented in Figure 319. 

A CELL CONDITION MEASUREMENT request indication is used by the 
25 MRRC to trigger the measurement of cell selecting information. This information 
flow requires a confirmation. The confirmation (CELL CONDITION 
MEASUREMENT response confirmation) provides the result of the measurement. 
The detail of the CELL CONDITION MEASUREMENT request indication is 
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represented in Figure 320. 

A CELL CONDITION MEASUREMENT response confirmation provides the 
result of the cell selection information measurement requested by the CELL 
CONDITION MEASUREMENT request indication. The detail of the CELL 
5 CONDITION MEASUREMENT response confirmation is represented in Figure 321. 

A CELL CONDITION REPORT request indication is used by the mobile 
terminal to report the cell selection information. The information is used by the 
network to select radio channels. This information flow does not require any 
confirmation. The detail is represented in Figure 322. 
10 An ADD-ROUTING INFORMATION request indication is sent to the LRDFp 

to add the routing information to the subscribers profile. This information flow is 
only sent when the authentic mobile terminal has been found and the above related 
information has been obtained. The detail is represented in Figure 323. 

An ADD-ROUTING INFORMATION response confirmation is a response to 
15 the ADD-ROUTING INFORMATION request indication. The detail of the ADD- 
ROUTING INFORMATION response confirmation is represented in Figure 324. 

A PAGE AUTHORIZED request indication at relationship rg is used to notify 
the TACF of the result of the terminal authentication. The detail is represented in 
Figure 325. 

20 A REVERSE LONG CODE RETRIEVAL response confirmation is used to 

retrieve the reverse long code. The detail is represented in Figure 326. 

A PAGE AUTHORIZED request indication is used to notify the TACF of the 
result of the terminal authentication. 

A ROUTING INFORMATION QUERY response confirmation is a response to 
25 the request indication. The detail is represented in Figure 327. The routing address 
item and TACF instance ID item in Figure 327 are used in this case to specify the 
routing information. The routing address item is used for routing in the visited 
network. 
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A SETUP request indication is used to request the establishment of a 
connection. The detail is represented in Figure 328. 

A TERMINATION ATTEMPT request indication is used to request the user's 
profile which may be needed to proceed the call process. The detail is represented in 
Figure 329. 

A USER PROFILE RETRIEVAL request indication is used to retrieve the 
called user's profile from the LRDF. The detail is represented in Figure 330. 

A USER PROFILE RETRIEVAL response confirmation is a response to the 
request indication from the LRCF. The detail is represented in Figure 331. 

A TERMINATION ATTEMPT response confirmation is a response to the 
request indication from the SSF. The detail is represented in Figure 332. 

A SETUP request indication is used to request the establishment of a 
connection. The detail is represented in Figure 333. 

A PROCEEDING request indication optionally reports that the instructed 
connection setup is valid and authenticated and that further routing and progressing 
of the call is proceeding. This information flow does not require any confirmation. 
The detail is represented in Figure 334. 

A MEASUREMENT CONDITION NOTIFICATION request indication is used 
by the network to indicate conditions, which the mobile terminal measures, and to 
report the cell selection information. When the mobile terminal is on an idle mode, 
the network indicates the MEASUREMENT CONDITION NOTIFICATION request 
indication periodically. When the mobile terminal is in communication, the network 
indicates the MEASUREMENT CONDITION NOTIFICATION request indication at 
the change of conditions. This information flow does not require any confirmation. 
The detail of the MEASUREMENT CONDITION NOTIFICATION request indication 
is represented in Figure 335. 

A REPORT request indication is an information element that is used to report 
status and/or other types of information transported in the network. The type of 
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information may be indicated (e.g. alerting, suspended, hold, resume). This 
information flow does not require any confirmation. The detail of the REPORT 
request indication is represented in Figure 336. 

A SETUP response confirmation is used to confirm that the connection has 
5 been established. The detail is represented in Figure 337. 

A CONNECTED request indication is used to acknowledge that a previously 
sent SETUP response confirmation has been received and accepted. This information 
flow does not require any confirmation. The detail is represented in Figure 338. 

10 2.4.2.3 CALL RELEASE 

2.4.2.3.1 DISCONNECTION INSTRUCTED BY USER 

(a) * FUNCTIONAL MODEL 

Figure 17 shows the functional model of a part of the invented system for 
describing the disconnection instructed by a user. 
15 (b) INFORMATION FLOWS 

Figure 18 is an information flow diagram showing the disconnection 
instructed by a user. 

(c) DEFINITIONS OF INFORMATION FLOWS 

A RELEASE request indication is used to release resources associated with a 
20 call connection, such as call ID or channels. This information flow requires a 
confirmation. The detail is represented in Figure 339. 

A RELEASE response confirmation is used to indicate that all resources 
pervasively associated with the connection have been released. The detail is 
represented in Figure 340. 
25 A TA RELEASE request indication is issued by the TACF to inform the SCF 

that an attempt of call release has been detected. This information flow is issued 
when the last call is released and the control relationship between the terminal and 
the network should be released. The detail is represented in Figure 341. 
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A TERMINAL-STATUS-MAKE-IDLE request indication is used to idle the 
terminal call status. The detail is represented in Figure 342. 

A TERMINAL-STATUS-MAKE-IDLE response confirmation is a response to 
the TERMINAL-STATUS-MAKE-IDLE request indication. The detail of the 
TERMINAL-STATUS-MAKE-IDLE response confirmation is represented in Figure 
343. 

ATA RELEASE response confirmation is used for the confirmation to the TA 
RELEASE request indication. The detail of the TA RELEASE response confirmation 
is represented in Figure 344. 

2.4.2.3.2 DISCONNECTION INSTRUCTED BY NETWORK 

(a) FUNCTIONAL MODEL 

Figure 19 shows the functional model of a part of the invented system for 
describing the disconnection instructed by the network. 

(b) INFORMATION FLOWS 

Figure 20 is an information flow diagram showing the disconnection 
instructed by the network. 

(c) DEFINITIONS OF INFORMATION FLOWS 

The information flow diagram will be described supplementally in the 
following and information elements in the flow diagram will be discussed and 
represented in tables. 

A RELEASE request indication is used to release resources associated with a 
call connection such as the call reference or channels. This information flow requires 
a confirmation. The detail is represented in Figure 345. 

A RELEASE response confirmation is used to indicate that all resources 
previously associated with the connection have been released. The detail is 
represented in Figure 346. 

ATA RELEASE request indication is issued by the TACF to inform the LRCF 
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that an attempt of call release has been detected. This information flow is issued 
when the last call is released and the control relationship between the terminal and 
the network should be released. The detail is represented in Figure 347. 

A TERMINAL-STATUS-MAKE-IDLE request indication is used to idle the 
terminal call status. The detail is represented in Figure 348. 

A TERMINAL-STATUS-MAKE-IDLE response confirmation is a response to 
the TERMINAL-STATUS-MAKE-IDLE request indication. The detail is represented 
in Figure 349. 

ATA RELEASE response confirmation is used for the response confirmation of 
the TERMINAL-STATUS-MAKE-IDLE request indication. The detail is represented 
in Figure 350. 

2.4.2.3.3 ABNORMAL RELEASE 

2.4.2.3.3.1 ABNORMAL RELEASE CAUSED FROM RADIO LINK FAILURE 

DETECTED BY MOBILE TERMINAL 

2.4.2.3.3.1.1 COMMON PROCEDURE MODULE USED 

A common procedure module used in this release process is the "user 
disconnect." 

2.4.2.3.3.1.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

Figure 21 shows the functional model of a part of the invented system for 
describing the abnormal release caused from a radio link failure (squelch condition) 
detected by a mobile terminal. 

b) INFORMATION FLOWS 

Figure 22 shows an information flow diagram of the abnormal release, 
executed in the communication control plane, caused from the radio link failure 
detected by the mobile terminal. 
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c) DEFINITIONS OF INFORMATION FLOWS AND INFORMATION 

ELEMENTS 

Information flows in Figure 22 will be described below and information 
elements of the flows are represented in tables. The order of description is the same 
as the order of the flows in Figure 22. 

A RADIO LINK FAILURE request indication is used to notify a radio link 
failure detected by the BCAF or BCFr. In this flow procedure, this information flow is 
issued by the BCAF. The detail is represented in Figure 351. 

A RELEASE NOTIFICATION request indication is used to indicate that the 
connection between the network and the terminal has been released. The 
information flow does not require any confirmation. The detail is represented in 
Figure 352. 

A RADIO LINK FAILURE request indication is used to notify that the link 
failure has been detected. The detail is represented in Figure 353. 

Another RADIO LINK FAILURE request indication is used to notify that the 
link failure has been detected. The detail is represented in Figure 354. 

A RADIO LINK FAILURE response confirmation is a response confirmation of 
the RADIO LINK FAILURE request indication. The detail is represented in Figure 
355. 

A RADIO BEARER RELEASE request indication is used to request to release 
radio bearers. This is originated by network. The detail is represented in Figure 
356. 

A TA RELEASE request indication is issued by the TACF to request the 
release of terminal access. This information flow is issued for only the last call 
release. 

A BEARER RELEASE request indication is issued by the TACF to the BCF to 
release the radio bearer. The detail is represented in Figure 357. 

A BEARER RELEASE response confirmation is a response confirmation of the 
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bearer release request indication. The detail is represented in Figure 358. 

Another BEARER RELEASE request indication is sent by the anchor TACF to 
request the serving TACF to release the bearer involved in the call that should be 
released. The detail is represented in Figure 359. 
5 Another BEARER RELEASE request indication is issued by the TACF to BCF 

to release the radio bearer. The detail is represented in Figure 360. 

Another BEARER RELEASE response confirmation is a response 
confirmation of the BEARER RELEASE request indication. The detail is represented 
in Figure 361. 

10 A BEARER-AND-RADIO-BEARER RELEASE request indication is issued by 

the TACF to release the bearer-and-radio-bearer. The detail is represented in Figure 
362. 

A BEARER-AND-RADIO-BEARER RELEASE response confirmation is used 

for a confirmation of the release of the bearer-and-radio-bearer requested by the 
15 BEARER-AND-RADIO-BEARER RELEASE request indication. The detail is 

represented in Figure 363. 

Another BEARER RELEASE response confirmation is a confirmation 

response to inform the TACF that the previous request to release the radio bearer has 

been completed. The detail is represented in Figure 364. 
20 A TA RELEASE request indication is issued by the TACF to inform the LRCF 

that the attempt of releasing call has detected. The detail is represented in Figure 

365. 

A TERMINAL-STATUS-MAKE-IDLE request indication is used to request to 
update the user profile. For call release, this information flow is used to update the 
25 user's call status to idle. The detail is represented in Figure 366. 

A TERMINAL-STATUS-MAKE-IDLE response confirmation is a response to 
the TERMINAL-STATUS-MAKE-IDLE request indication. The detail is represented 
in Figure 367. 
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ATA RELEASE response confirmation is used for a response confirmation of 
the TA RELEASE request indication. The detail is represented in Figure 368. 

2.4.2.3.3.2 ABNORMAL RELEASE CAUSED FROM RADIO LINK FAILURE 
DETECTED BY NETWORK 

2.4.2.3.3.2. 1 COMMON PROCEDURE MODULE USED 

A common procedure module used in this release process is the "user 
disconnect." 

2.4.2.3.3.2.2 INFORMATION FLOW- DIAGRAM 

a) FUNCTIONAL MODEL 

Figure 23 shows the functional model of a part of the invented system for 
describing the abnormal release caused from a radio link failure (squelch condition) 
detected by the network. 

b) INFORMATION FLOWS 

Figure 24 shows an information flow diagram of the abnormal release, 
executed in the communication control plane, caused from the radio link failure 
detected by the network. 

c) DEFINITIONS OF INFORMATION FLOWS AND INFORMATION 
ELEMENTS 

Information flows in Figure 24 will be described below and information 
elements of the flows are represented in tables. The order of description is the same 
as the order of the flows in Figure 24. 

A RADIO LINK FAILURE request indication is used to notify that a link 
failure has been detected and reported by either BCFr or BCFa. The detail is 
represented in Figure 369. 

Another RADIO LINK FAILURE request indication is used to notify that the 
link failure has been detected. The detail is represented in Figure 370. 

A RADIO LINK FAILURE response confirmation is a confirmation response to 
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the RADIO LINK FAILURE request indication. The detail is represented in Figure 
371. 

A RADIO BEARER RELEASE request indication is used to request to release 
the radio bearer. This is originated by the network. The detail is represented in 
5 Figure 372. 

A RELEASE NOTIFICATION request indication is used to indicate that the 
connection between the network and the terminal has been released. The 
information flow does not require any confirmation. The detail is represented in 
Figure 373. 

10 A RADIO BEARER RELEASE response confirmation is a response 

confirmation of the RADIO BEARER RELEASE request indication. The detail is 
represented in Figure 374. 

A TA RELEASE request indication is issued by the TACF to request the 
release of terminal access. This information flow is issued for only the last call. 
15 A TA RELEASE response confirmation is a response confirmation of the TA 

RELEASE request indication. 

A BEARER RELEASE request indication is issued by the TACF to BCF to 
release the radio bearer. The detail is represented in Figure 375. 

A BEARER RELEASE response confirmation is a response confirmation of the 
20 BEARER RELEASE request indication. The detail is represented in Figure 376. 

Another BEARER RELEASE request indication is sent by the anchor TACF to 
request the serving TACF to release the radio bearer involved in the call that should be 
released. The detail is represented in Figure 377. 

Another BEARER RELEASE request indication is issued by the TACF to BCF 
25 to release the radio bearer. The detail is represented in Figure 378. 

A BEARER RELEASE response confirmation is a response confirmation of the 
BEARER RELEASE request indication. The detail is represented in Figure 379. 

A BEARER- AND -RADIO-BEARER RELEASE request indication is issued by 
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the TACF to release the bearer-and-radio-bearer. The detail is represented in Figure 
380. 

A BEARER-AND-RADIO-BEARER RELEASE response confirmation is used 
for a confirmation of the release of the bearer and radio bearer requested by the 
5 BEARER-AND-RADIO-BEARER RELEASE request indication. The detail is 
represented in Figure 381. 

Another BEARER RELEASE response confirmation is a confirmation 
response for informing the TACF that the previous request to release the radio bearer 
has been completed. The detail is represented in Figure 382. 
10 A RADIO BEARER RELEASE request indication is issued to request to 

release the radio bearer. The detail is represented in Figure 383. 

Another RADIO BEARER RELEASE response confirmation is used to confirm 
the release of radio bearer requested by the RADIO BEARER RELEASE request 
indication. The detail is represented in Figure 384. 
15 A TA RELEASE request indication is issued by the TACF to inform the LRCF 

that the attempt of call release has been detected. The detail is represented in Figure 
385. 

A TERMINAL-STATUS-MAKE-IDLE request indication is used to request to 
update the user profile. For call release, this information flow is used to update the 
20 user's call status to idle. The detail is represented in Figure 386. 

A TERMINAL-STATUS-MAKE-IDLE response confirmation is a response to 
the TERMINAL-STATUS-MAKE-IDLE request indication. The detail is represented 
in Figure 387. 

Another TA RELEASE response confirmation is used for confirmation to the 
25 TA RELEASE request indication. The detail is represented in Figure 388. 

2.4.2.3.4 USER DISCONNECT 

2.4.2.3.4.1 INFORMATION FLOW DIAGRAM 
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a) FUNCTIONAL MODEL 

Figure 25 shows the functional model of a part of the invented system for 
describing the "user disconnect." 

b) INFORMATION FLOWS 

Figure 26 shows an information flow diagram of the "user disconnect." 

c) DEFINITIONS OF INFORMATION FLOWS AND INFORMATION 
ELEMENTS 

Information flows in Figure 26 will be described below and information 
elements in the flows are represented in tables. The order of description is the same 
as the order of the flows in Figure 26. 

A CALL DISCONNECT request indication is used to notify the LRCF that a 
"user disconnect" has been detected. The detail is represented in Figure 389. 

A USER-PROFILE-UPDATE request indication is used to request to update 
the user profile. For call release, this information flow is used to indicate the call has 
been released. The detail is represented in Figure 390. 

A USER-PROFILE-UPDATE response confirmation is a response to the 
USER-PROFILE-UPDATE response confirmation. The detail is represented in 
Figure 391. 

A CALL DISCONNECT response confirmation is a response to the request 
made by the CALL DISCONNECT request indication. The detail is represented in 
Figure 392. 



2.4.3 INFORMATION FLOW DIAGRAMS FOR ACCESS LINK CONTROL 

2.4.3.1 SDCCH SETUP 

First, the SDCCH setup process will be described. 

2.4.3.1.1 COMMON PROCEDURE MODULES USED 

2.4.3.1.2 INFORMATION FLOW DIAGRAM 
a) FUNCTIONAL MODEL 
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Figure 27 shows the functional model of a part of the invented system for 
describing the SDCCH setup process. 

b) INFORMATION FLOWS 

Figure 28 shows an information flow diagram of the SDCCH setup process. 

c) DEFINITIONS OF INFORMATION FLOWS AND INFORMATION 
ELEMENTS 

Information flows in Figure 28 will be described below and information 
elements of the flows are represented in tables. The order of description is the same 
as the order of the flows in Figure 28. 

A SIGNALING CHANNEL SETUP REQUEST request indication is used by 
the MCF and TACF to request the network to setup the signaling channels. The 
detail is represented in Figure 393. 

A SIGNALING CHANNEL SETUP request indication is used by the SCMAF 
to request to the network to allocate the signaling channels. The detail is represented 
in Figure 394. 

A SIGNALING CHANNEL SETUP response confirmation is used by the 
SCMF to allocate the radio resources to the signaling channels. The detail is 
represented in Figure 395. 

A SIGNALING CHANNEL SETUP REQUESTED request indication is used 
to indicate the reception of the signaling channel setup request (initial access 
detection) from the mobile terminal and to request the network to setup the 
corresponding signaling channels in the network. The detail is represented in Figure 
396. 

A SIGNALING CONNECTION SETUP request indication is used by the 
TACF and SACF to setup the signaling connection among them and the SCMF. The 
detail is represented in Figure 397. 

A SIGNALING CONNECTION SETUP response confirmation is used to 
report the establishment of the signaling channels including the physical radio 
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channel and the intra-network channel. The detail is represented in Figure 398. 

A SIGNALING CHANNEL SETUP REQUEST response confirmation is used 
by the SCMAF to report the setup of the signaling channels to the network. The 
detail is represented in Figure 399. 

5 

2.4.3.2 BEARER SETUP 

Next, bearer setup procedures for the radio resource selection will be 
described, 

2.4.3.2.1 COMMON PROCEDURE MODULES USED 

10 2.4.3.2.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

Radio resources are selected under a base station which is different from the 
one that received a call setup request from a mobile terminal while the BSs are 
controlled by different TACFs. The CCF only has the relationship with the TACFa 
15 and does not have the relationship with the TACFv. The TACFa controls both bearer 
selection and bearer setup. There are three BCFs: BCF1, BCF2, and BCFr. 

Figure 29 shows the functional model of a part of the invented system for 
describing the bearer setup for the radio resource selection. 

b) INFORMATION FLOWS 

20 Figure 30 shows an information flow diagram of the bearer setup, executed in 

the communication control plane, for the radio resource selection. 

2.4.3.2.2.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION 
ELEMENTS 

25 Information flows in Figure 30 will be described below and information 

elements of the flows are represented in tables. The order of description is the same 
as the order of the flows in Figure 30. 

A BEARER SETUP request indication is used to request the establishment of 
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the access bearer from the CCF to TACF. The detail is represented in Figure 400. 
The information elements asterisked in Figure 400 are contained in the bearer 
capability element in Figure 286 sent from the CCAF. 

A CHANNEL SELECTION request indication is used by the TACF to request 
to select and reserve radio resources which can support the required bearer capability. 
This interaction occurs when new radio resources are necessary for call setup and 
handover. 

A CHANNEL SELECTION response confirmation is used to report the 
reserved radio resources to the TACF, which requested the reservation. The detail is 
represented in Figure 401. 

A BEARER SETUP request indication is sent from the TACF to BCF to 
request the establishment of the access bearer. The detail is represented in Figure 
402. 

A BEARER SETUP response confirmation is sent to confirm the 
establishment of the access bearer and to indicate the bearer ID of the bearer between 
the BCF and BCF. The detail is represented in Figure 403. 

Another BEARER SETUP request indication is used to request the 
establishment of the access bearer from the TACFa to TACFv. The detail is 
represented in Figure 404. 

Another BEARER SETUP request indication is sent from the TACF to BCF to 
request the establishment of the access bearer. The detail is represented in Figure 
405. 

Another BEARER SETUP response confirmation is sent from the BCF to 
TACF to request the establishment of the access bearer. The detail is represented in 
Figure 406. 

A BEARER-AND-RADIO-BEARER SETUP request indication is sent from the 
TACF to BCFr to request the establishment of the radio bearer and the bearer between 
the BCF and BCFr. The detail is represented in Figure 407. 
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A RADIO BEARER SETUP PROCEEDING request indication is used by the 
BCFr to report that the instructed radio bearer setup is valid and the establishment of 
the radio bearer is proceeding. This information flow does not require any 
confirmation. The detail is represented in Figure 408. 

A RADIO BEARER SETUP REQUEST request indication is issued by the 
TACF, which controls a new access bearer, to the TACF, which has the signaling 
connection, to request to newly assign a radio bearer to the mobile terminal. The 
detail is represented in Figure 409. 

A RADIO BEARER SETUP request indication is sent from the TACF to 
TACAF to request the establishment of the radio bearer. The detail is represented in 
Figure 410. 

Another RADIO BEARER SETUP request indication is sent from the TACAF 
to BCAF to request the establishment of the radio bearer. The detail is represented in 
Figure 411. 

A RADIO BEARER SETUP response confirmation is sent from the BCAF to 
TACAF to confirm that the establishment of radio bearer has been completed. The 
detail is represented in Figure 412. 

A BEARER-AND-RADIO-BEARER SETUP response confirmation is sent to 
confirm that the establishment of radio bearer and bearer between the BCF and BCFr 
have been completed. The detail is represented in Figure 413. 

A BEARER SETUP response confirmation is used to confirm that the 
establishment of access bearer has been completed. The detail is represented in 
Figure 414. 

Another BEARER SETUP response confirmation is used to confirm that the 
establishment of access bearer has been completed. The detail is represented in 
Figure 415. 



2.4.3.3 



RADIO BEARER RELEASE 
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2.4.3.3.1 RADIO BEARER RELEASE FOR TACF ANCHOR APPROACH 

2.4.3.3.1.1 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

Figure 31 shows the functional model of a part of the invented system for 
describing the radio bearer release. 

b) INFORMATION FLOWS 

Figure 32 shows an information flow diagram of the radio bearer release. 

2.4.3.3.1.2 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION 
ELEMENTS 

Information flows in Figure 32 will be described below and information 
elements of the flows are represented in tables. The order of description is the same 
as the order of the flows in Figure 32. 

A BEARER RELEASE request indication is sent by the anchor CCF to notify 
the anchor TACF that the attempt or event of call release has been detected and that 
the bearer involved in the call is being released. The detail is represented in Figure 
416. 

A RADIO BEARER RELEASE request indication is used by the TACFa to 
request to release the radio bearer. This is originated by the network. The detail is 
represented in Figure 417. 

A RADIO BEARER RELEASE response confirmation is a response 
confirmation of the RADIO BEARER RELEASE request indication. The detail is 
represented in Figure 418. 

A TA RELEASE request indication is issued by the TACFa to request the 
release of the terminal access. This information flow is issued only for the last call 
release. 

A TA RELEASE response confirmation is a response confirmation of the TA 
RELEASE request indication. 
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A BEARER RELEASE request indication is issued by the TACF to BCF to 
release the radio bearer. The detail is represented in Figure 419. 

A BEARER RELEASE response confirmation is a response confirmation of the 
BEARER RELEASE request indication. The detail is represented in Figure 420. 
5 Another BEARER RELEASE request indication is sent by the TACFa to 

request the TACFv to release the bearer involved in the call is being released. The 
detail is represented in Figure 421. 

Another BEARER RELEASE request indication is issued by the TACF to BCF 
to release the radio bearer. The detail is represented in Figure 422. 
10 A BEARER RELEASE response confirmation is a response confirmation of the 

BEARER RELEASE request indication. The detail is represented in Figure 423. 

A BEARER-AND-RADIO-BEARER RELEASE request indication is issued by 
the TACF to release the bearer and radio bearer. The detail is represented in Figure 
424. 

15 A BEARER-AND-RADIO-BEARER RELEASE response confirmation is used 

for a confirmation of the release of the bearer and radio bearer requested by the 
BEARER-AND-RADIO-BEARER RELEASE request indication. The detail is 
represented in Figure 425. 

Another BEARER RELEASE response confirmation is a confirmation of the 
20 BEARER RELEASE request indication. The detail is represented in Figure 426. 

Another BEARER RELEASE response confirmation is a „ response 
confirmation to inform the CCF that the previous request to release the radio bearer 
has been completed. The detail is represented in Figure 427. 

Another RADIO BEARER RELEASE request indication is issued by the 
25 TACAF to request the radio bearer release. The detail is represented in Figure 428. 

Another RADIO BEARER RELEASE request indication is used by the BCAF 
to confirm the radio bearer release requested by the RADIO BEARER RELEASE 
request indication. The detail is represented in Figure 429. 
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2.4.3.4 SDCCH RELEASE 

Next, SDCCH release procedures will be described. 
2.4.3.4.1 COMMON PROCEDURE MODULES USED 

5 2.4.3.4.2 INFORMATION FLOW DIAGRAM " 

a) FUNCTIONAL MODEL 

Figure 33 shows the functional model of a part of the invented system for 
describing the SDCCH release. 

b) INFORMATION FLOWS 

10 Figure 34 shows an information flow diagram of the SDCCH release. 



2.4.3.4.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION 

ELEMENTS 

Information flows in Figure 34 will be described below and information 
15 elements of the flows are represented in tables. The order of description is the same 
as the order of the flows in Figure 34. 

A SIGNALING CHANNEL RELEASE REQUEST request indication is used 
by the MCF and TACF to request the release of a signaling channel. The detail is 
represented in Figure 430. 
20 A SIGNALING CONNECTION RELEASE request indication is used by the 

TACF and SACF to request the release of the signaling channel (in both of the network 
and the radio resources). The detail is represented in Figure 431. 

A SIGNALING CONNECTION RELEASE response confirmation is used to 
report the release of the signaling channel. The detail is represented in Figure 432. 

25 



2.4.3.5 
2.4.3.5.0 
Process 1: 



HANDOVER 

HANDOVER PROCESS AND RELEVANT PROCEDURE MODULES 
Handover trigger 
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Detection of handover triggering. 
Process 2: Handover resource reservation 

Reservation of radio resources for handover. 
Process 3: Handover execution 
5 Preparing at network side, if any. 

Request the mobile terminal as indicated by trigger. 
Process 4: Handover completion 

Release of unneeded radio bearer and resources. 

Figure 35 shows a flow chart showing handover processes in general. Figure 
10 36 is an information flow diagram showing processes 1 and 2 described above. 

Figure 37 is an information flow diagram representing a sequence in which 
information flows are transported for starting non-soft handover execution, the 
sequence corresponding to process 1 in Figure 35. Figure 38 is an information flow 
diagram representing a sequence in which information flows are transported for 
15 starting handover branch addition, the sequence corresponding to process 1 in Figure 
35. Figure 39 is an information flow diagram representing a sequence in which 
information flows are transported for starting handover branch deletion, the sequence 
corresponding to process 1 in Figure 35. 




20 2.4.3.5.1 INTER-SECTOR HANDOVER BRANCH ADDITION IN SINGLE 

CELL i 

(HANDOVER CONTROLLED BY SAME BCFr) 

2.4.3.5.1.1 COMMON PROCEDURE MODULES 

2.4.3.5.1.2 INFORMATION FLOW DIAGRAM 
25 a) FUNCTIONAL MODEL 

Figure 40 shows the functional model of a part of the invented system for 
describing the inter-sector handover branch addition in a single cell, 
b) INFORMATION FLOWS 



F0220/2551 



169 

Figure 41 shows an information flow diagram of the inter-sector handover 
branch addition in a single cell, executed in the communication control plane. 
2.4.3.5.1.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION 

ELEMENTS 

Information flows in Figure 41 will be described below and information 
elements of the flows are represented in tables. 

A BEARER SETUP request indication is sent from the TACFa to TACFv to 
request the setup of an access bearer. The detail is represented in Figure 433. This 
information flow identifies the bearer between the BCFa and BCFv. 

An INTRA-BCFr HANDOVER BRANCH ADDITION request indication is 
sent from the TACF to BCFr to request to setup new physical radio channel(s). The 
detail is represented in Figure 434. 

An INTRA-BCFr HANDOVER BRANCH ADDITION response confirmation is 
a response to the INTRA-BCFr HANDOVER BRANCH ADDITION request indication 
and is sent from the BCFr to TACF to indicate the completion of setup of the physical 
radio channel(s). The detail is represented in Figure 435. 

A RADIO BEARER SETUP REQUEST request indication is sent from the 
visited TACF, which controls the newly assigned radio bearer, to TACFa to request to 
setup the radio bearer between the mobile terminal and BCFr controlled by the visited 
TACF. The detail is represented in Figure 436. 

A HANDOVER BRANCH ADDITION request indication is sent from the 
TACF to TACAF to notify of the intra-BCFr handover branch addition, and requests to 
add a new physical radio channel to an existing physical radio channel. The detail is 
represented in Figure 437. The information element marked by *1 in Figure 437 
may be repeated a plurality of times, the number of repetition is the same as the 
number of the handover branches at the mobile terminal. The information elements 
marked by *2 in Figure 437 may be repeated a plurality of times, the number of 
repetition is the same as the number of the calls related to the TACF. 
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A HANDOVER BRANCH ADDITION response confirmation is sent from the 
TACAF to TACF to notify of the reception of the HANDOVER BRANCH ADDITION 
request indication. 

A RADIO BEARER SETUP request indication is sent from the TACAF to 
5 BCAF to request to setup a radio bearer. The detail is represented in Figure 438. 

A RADIO BEARER SETUP response confirmation is a response to the RADIO 
BEARER SETUP request indication sent from the BCAF to TACAF to indicate the 
completion of the radio bearer setup. The detail is represented in Figure 439. 

10 2.4.3:5.2 INTER-CELL HANDOVER BRANCH ADDITION 

2.4.3.5.2. 1 COMMON PROCEDURE MODULES 

2.4.3.5.2.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

Figure 42 shows the functional model of a part of the invented system for 
15 describing the inter-cell handover branch addition. 

b) INFORMATION FLOWS 

Figure 43 shows an information flow diagram of the inter-cell handover 
branch addition, executed in the communication control plane. 

20 2.4.3.5.2.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION 

ELEMENTS 

A HANDOVER CONNECTION SETUP request indication is sent from the 
TACFa to BCFa to notify of a handover initiation and to request to setup an access 
bearer. The detail is represented in Figure 440. The information element marked 
25 by *1 in Figure 440 identifies the bearer between the CCF and BCF. 

A HANDOVER CONNECTION SETUP response confirmation is sent from 
the BCF to TACF to confirm the HANDOVER CONNECTION SETUP request 
indication. The detail is represented in Figure 441. The asterisked information 
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element in Figure 441 identifies the bearer between the BCFa and BCFv. 

A BEARER SETUP request indication is sent from the TACFa to TACFv to 
setup an access bearer. The detail is represented in Figure 442. The asterisked 
information element in Figure 442 identifies the bearer between the BCFa and BCFv. 

Another BEARER SETUP request indication is sent from the TACF to BCF to 
request the bearer setup. The detail is represented in Figure 443. The asterisked 
information element in Figure 443 identifies the bearer between the BCF and CCF. 

A BEARER SETUP response confirmation is sent from the BCF to TACF to 
confirm the BEARER SETUP request indication. The detail is represented in Figure 
444. The asterisked information element in Figure 444 identifies the bearer between 
the BCF and BCFr. 

A BEARER-AND-RADIO-BEARER SETUP request indication is sent from the 
TACF to BCFr to request to setup a bearer between the BCF and BCFr and a radio 
bearer. The detail is represented in Figure 445. 

A BEARER-AND-RADIO-BEARER SETUP response confirmation is a 
response to the BEARER-AND-RADIO-BEARER SETUP request indication and is 
sent from the BCFr to TACF to indicate the completion of setting up of the radio bearer 
and bearer between the BCFr and BCF. The detail is represented in Figure 446. 

A RADIO BEARER SETUP REQUEST request indication is sent from the 
visited TACF, which controls the newly assigned radio bearer, to the TACFa to request 
to setup the radio bearer between the mobile terminal and BCFr. The detail is 
represented in Figure 447. 

A HANDOVER BRANCH ADDITION request indication is sent from the 
TACF to TACAF to notify of the HANDOVER BRANCH ADDITION request indication 
and to request to setup a new physical radio channel(s) without releasing the existing 
physical radio channel(s). The detail is represented in Figure 448. The information 
elements marked by *1 in Figure 448 may be repeated a plurality of times, the number 
of repetition is the same as the number of the destination cells. The information 
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elements marked by *2 in Figure 448 may be repeated a plurality of times, the number 
of repetition is the same as the number of the calls related to the TACF. 

A HANDOVER BRANCH ADDITION response confirmation is sent from the 
TACAF to TACF to notify of the reception of the HANDOVER BRANCH ADDITION 
INITIATION request indication. 

A RADIO BEARER SETUP request indication is sent from the TACAF to 
BCAF to request to setup a radio bearer. The detail is represented in Figure 449. 

A RADIO BEARER SETUP response confirmation is a response to the RADIO 
BEARER SETUP request indication and is sent from the BCAF to TACAF to indicate 
the completion of the radio bearer setup. The detail is represented in Figure 450. 

A BEARER SETUP response confirmation is sent from the TACFa to TACFv 
to confirm the establishment of the access bearer. The detail is represented in Figure 
451. 

2.4.3.5.3 INTER-SECTOR HANDOVER BRANCH DELETION IN SINGLE 

CELL (HANDOVER CONTROLLED BY SAME BCFr) 

2.4.3.5.3. 1 COMMON PROCEDURE MODULES 

2.4.3.5.3.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

Figure 44 shows the functional model of a part of the invented system for 
describing the inter-sector handover branch deletion in a single cell. 

b) INFORMATION FLOWS 

Figure 45 shows an information flow diagram of the inter-sector handover 
branch deletion in a single cell, executed in the communication control plane. 

2.4.3.5.3.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION 
ELEMENTS 

A HANDOVER BRANCH DELETION request indication is sent from the 
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TACF to TACAF to request to release the physical radio channel(s). The detail is 
represented in Figure 452. The information elements marked by *1 in Figure 452 
may be repeated a plurality of times, the number of repetition is the same as the 
number of the handover branches related to the terminal. The information elements 
marked by *2 in Figure 452 may be repeated a plurality of times, the number of 
repetition is the same as the number of the calls related to the terminal. The 
Handover branch ID element in Figure 452 is used to uniquely identify the route by 
which an access link is carried. 

A HANDOVER BRANCH DELETION response confirmation is sent from the 
TACAF to TACF to confirm the HANDOVER BRANCH DELETION request indication. 
The detail is represented in Figure 453. 

A BEARER RELEASE request indication is sent from the TACFa to TACFv to 
release the access bearer. The detail is represented in Figure 454. 

An INTRA- BCFr HANDOVER BRANCH DELETION request indication is 
sent from the TACF to BCFr to request the release of the physical radio channel(s). 
The detail is represented in Figure 455. The asterisked information element in 
Figure 455 is included when this information flow is sent from BCFr to TACF. 

An INTRA-BCFr HANDOVER BRANCH DELETION response confirmation 
is a response to the INTRA-BCFr HANDOVER BRANCH DELETION request 
indication and is sent from the BCFr to TACF to indicate the release of the physical 
radio channel(s). The detail is represented in Figure 456. 

A BEARER RELEASE response confirmation is sent from the TACFv to 
TACFa to confirm the BEARER RELEASE request indication. The detail is 
represented in Figure 457. 

2.4.3.5.4 INTER-CELL HANDOVER BRANCH DELETION AT LOCATIONS 



OTHER THAN BOUNDARY BETWEEN CELLS 



2.4.3.5.4.1 



COMMON PROCEDURE MODULES 



F0220/2551 



174 

2.4.3.5.4.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

Figure 46 shows the functional model of a part of the invented system for 
describing the inter-cell handover branch deletion. 

b) INFORMATION FLOWS 

Figure 47 shows an information flow diagram of the inter-cell handover 
branch deletion, executed in the communication control plane. 

2.4.3.5.4.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION 
ELEMENTS 

Information flows in Figure 47 will be described below and information 
elements of the flows are represented in tables. 

A HANDOVER BRANCH DELETION request indication is sent from the 
TACF to TACAF to request to release the physical radio channel(s). The detail is 
represented in Figure 458. The information elements marked by *1 in Figure 458 
may be repeated a plurality of times, the number of repetition is the same as the 
number of the handover branches related to the terminal. The information element 
marked by *2 in Figure 458 may be repeated a plurality of times, the number of 
repetition is the same as the number of the calls related to the terminal. The 
handover branch ID element in Figure 458 is used to uniquely identify the route by 
which an access radio link is carried. 

A HANDOVER BRANCH DELETION response confirmation is sent from the 
TACAF to TACF to confirm the HANDOVER BRANCH DELETION request indication. 
The detail is represented in Figure 459. 

A RADIO BEARER RELEASE request indication is sent from the TACAF to 
BCAF to request the radio bearer release. The detail is represented in Figure 460. 

A RADIO BEARER RELEASE response confirmation is a response to the 
RADIO BEARER RELEASE request indication and is sent from the BCFr to TACAF to 
indicate the completion of the radio bearer release. The detail is represented in 
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Figure 461. 

A HANDOVER CONNECTION RELEASE request indication is sent from the 
TACF to BCF to release the indicated bearer in the diversity handover state. The 
detail is represented in Figure 462. 
5 A HANDOVER CONNECTION RELEASE response confirmation is sent from 

the BCF to TACF to confirm the HANDOVER CONNECTION RELEASE request 
indication. The detail is represented in Figure 463. x 

A BEARER RELEASE request indication is sent from the TACFa to TACFv to 
release the access bearer. The detail is represented in Figure 464. 
10 Another BEARER RELEASE request indication is sent from the TACF to BCF 

to request the bearer release. The detail is represented in Figure 465. 

A BEARER RELEASE response confirmation is sent from the BCF to TACF to 
confirm the BEARER RELEASE request indication. The detail is represented in 
Figure 466. 

15 A BEARER- AND-RADIO -BEARER RELEASE request indication is sent from 

the TACF to BCFr to request the bearer between the BCF and BCFr and the radio 
bearer. The detail is represented in Figure 467. The asterisked information element 
in Figure 467 is included when this information flow is sent from BCFr to TACF. 

A BEARER-AND-RADIO-BEARER RELEASE response confirmation is a 

20 response to the BEARER-AND-RADIO-BEARER RELEASE request indication and is 
sent from the BCFr to TACF to indicate the completion of the release of the bearer and 
the radio bearer. The detail is represented in Figure 468. 

A BEARER RELEASE response confirmation is sent from the TACFv to 
TACFa to confirm the BEARER RELEASE request indication. The detail is 

25 represented in Figure 469. 

2.4.3.5.5 INTRA-CELL BRANCH REPLACEMENT HANDOVER 

2.4.3.5.5.1 COMMON PROCEDURE MODULES USED 
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2.4.3.5.5.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

Figure 48 shows the functional model of a part of the invented system for 
describing the intra-cell branch replacement handover. 

b) INFORMATION FLOWS 

Figure 49 shows an information flow diagram of the intra-cell branch 
replacement handover executed in the communication control plane. 

2.4.3.5.5.3 DEFINITIONS OF INFORMATION FLOWS AND INFORMATION 
ELEMENTS 

Information flows in Figure 49 will be described below and information 
elements of the flows are represented in tables. 

A BEARER SETUP request indication is sent from the TACFa to TACFv to 
setup an access bearer. The detail is represented in Figure 470. The asterisked 
information element in Figure 470 identifies the bearer between the BCFa and BCFv. 

An INTRA-BCFr HANDOVER BRANCH REPLACEMENT request indication 
is sent from the TACF to BCFr to request to set up new physical radio channel(s). 

An INTRA-BCFr HANDOVER BRANCH REPLACEMENT response 
confirmation is a response to the INTRA-BCFr HANDOVER BRANCH 
REPLACEMENT request indication and is sent from the BCFr to TACF to indicate the 
completion of the setup of the physical radio channel(s). The detail is represented in 
Figure 471. The information element marked by *1 in Figure 471 may be repeated a 
plurality of times, the number of repetition is the same as the number of the radio 
links to be setup. 

An INTRA-BCFr HANDOVER BRANCH REPLACEMENT PROCEEDING 
request indication is sent from the BCFr to TACF to indicate that the request of the 
handover branch replacement is accepted. The detail is represented in Figure 472. 

A RADIO BEARER SETUP REQUEST request indication is sent from the 
visited TACF, which controls the newly assigned radio bearer, to the anchor TACFa to 
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request to setup the radio bearer between the mobile terminal and BCFr controlled by 
the visited TACF. The detail is represented in Figure 473. 

A NON-SOFT HANDOVER EXECUTION request indication is sent from the 
TACF to TACAF to notify of a non-soft handover execution request initiation and to 
request to replace an existing radio channel by the designated physical radio channel. 
The detail is represented in Figure 474. The information element marked by *1 in 
Figure 474 may be repeated a plurality of times, the number of repetition is the same 
as the number of the handover branches related to the terminal. The information 
element marked by *2 in Figure 474 may be repeated a plurality of times, the number 
of repetition is the same as the number of the calls related to the TACF. 

A RADIO BEARER SETUP request indication is sent from the TACAF to 
BCAF to request to setup a radio bearer. The detail is represented in Figure 475. 

A RADIO BEARER SETUP response confirmation is a response to the RADIO 
BEARER SETUP request indication and is sent from the BCAF to TACAF to indicate 
the completion of the radio bearer setup. The detail is represented in Figure 476. 

A RADIO BEARER RELEASE request indication is sent from the TACAF to 
BCAF to request the radio bearer release. The detail is represented in Figure 477. 

A RADIO BEARER RELEASE response confirmation is a response to the 
RADIO BEARER RELEASE request indication and is sent from the BCAF to TACAF 
to indicate the completion of the radio bearer release. The detail is represented in 
Figure 478. 

A BEARER SETUP response confirmation is sent from the TACFa to TACFv 
to confirm the establishment of the access bearer. The detail is represented in Figure 



- 479. 



2.4.3.5.6 



INTER-CELL BRANCH REPLACEMENT HANDOVER 



2.4.3.5.6.1 



COMMON PROCEDURE MODULES USED 



2.4.3.5.6.2 



INFORMATION FLOW DIAGRAM 
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FUNCTIONAL MODEL 




20 



Figure 50 shows the functional model of a part of the invented system for 
describing the inter-cell branch replacement handover. 



Figure 51 shows an information flow diagram of the inter-cell branch 
replacement handover executed in the communication control plane. 

2.4.3.5.6.3 DEFINITIONS OF INFORMATION FLOWS AND ASSOCIATED 

INFORMATION ELEMENTS 

Information flows in Figure 51 will be described below and information 
elements of the flows are represented in tables. 

A HANDOVER CONNECTION SETUP request indication is sent from the 
TACFa to BCFa to notify of a handover initiation and to request to set up a new 
handover link. The detail is represented in Figure 480. The information element 
marked by *1 in Figure 480 is mandatory in case that the network has more than one 
handover mode. 

A HANDOVER CONNECTION SETUP response confirmation is sent from 
the BCF to TACF to confirm the HANDOVER CONNECTION SETUP request 
indication. The detail is represented in Figure 481. The asterisked information 
element in Figure 481 identifies the bearer between the BCFa and BCFv. 

A BEARER SETUP request indication is sent from the TACFa to TACFv to set 
up a new handover link. The detail is represented in Figure 482. The asterisked 
information element in Figure 482 identifies the link between the BCFa and BCFv. 
There may be another functional entity for transition of link between the BCFa and 
BCFv. The expression of inter-BCF link should be studied further. 

Another BEARER SETUP request indication is sent from the TACF to BCF to 
request a new handover link in the network. The detail is represented in Figure 483. 
The asterisked information element in Figure 483 identifies the link between the 



b) 



INFORMATION FLOWS 
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BCFa and BCFv. There may be another functional entity for transition of link 
between the BCFa and BCFv. The expression of inter-BCF link should be studied 
further. 

A BEARER SETUP response confirmation is sent from the BCF to TACF to 
5 confirm a BEARER SETUP request indication. The detail is represented in Figure 
484. The asterisked information element in Figure 484 identifies the link between 
the BCF and BCFr. There may be another functional entity for transition of link 
between the BCFa and BCFv. The expression of inter-BCF link should be studied 
further. 

10 A BEARER- AND-RADIO-BEARER SETUP request indication is sent from the 

TACF to BCFr to request to set up a bearer between the BCF and BCFr and a radio 

bearer. The detail is represented in Figure 485. 

A RADIO BEARER SETUP PROCEEDING request indication is sent from the 

BCFr to TACF to indicate that the request of the access radio link setup is accepted 
15 and that the BCFr starts setting up the access radio link. The detail is represented in 

Figure 486.i 

A RADIO BEARER SETUP REQUEST request indication is sent from the 
visited TACF, which controls the newly assigned access radio link, to TACFa to request 
to set up the access radio link between the mobile terminal and the BCFr controlled by 

20 the visited TACF. The detail is represented in Figure 487. 

A NON-SOFT HANDOVER EXECUTION request indication is sent from the 
TACF to TACAF to notify of a NON-SOFT HANDOVER EXECUTION request 
indication and to request to replace an existing physical radio channel by a designated 
physical radio channel. The detail is represented in Figure 488. The information 

25 element marked by *1 in Figure 488 may be repeated a plurality of times, the number 
of repetition is the same as the number of the handover branches related to the 
terminal. The information element marked by *2 in Figure 488 may be repeated a 
plurality of times, the number of repetition is the same as the number of the access 
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links related to the TACF. 

A RADIO BEARER SETUP request indication is sent from the TACAF to 
BCAF to request to set up an access radio link. The detail is represented in Figure 
489. 

5 A RADIO BEARER SETUP response confirmation is a response to the RADIO 

BEARER SETUP request indication and is sent from the BCAF to TACAF to indicate 
the completion of the setup of the access radio link. The detail is represented in 
Figure 490. 

A RADIO BEARER RELEASE request indication is sent from the TACAF to 
10 BCAF to request to release the access radio link. The detail is represented in Figure 
491. 

A RADIO BEARER RELEASE response confirmation is a response to the 
RADIO BEARER RELEASE request indication and is sent from the BCAF to TACAF 
to request to release the access radio link. The detail is represented in Figure 492. 
15 A BEARER-AND-RADIO-BEARER SETUP response confirmation is a 

response to the BEARER: AND-RADIO-BEARER SETUP request indication and is 
sent from the BCFr to TACF to indicate the completion of the setup of the access radio 
link and the link between the BCFr and BCF. The detail is represented in Figure 
493. 

20 A BEARER SETUP response confirmation is sent from the TACF a to TACFv 

to confirm the establishment of the handover link. The detail is represented in 
Figure 494. 

A HANDOVER CONNECTION RELEASE request indication is sent from the 
TACF to BCFa to request to remove the indicated handover link. The detail is 
25 represented in Figure 495. 

A HANDOVER CONNECTION RELEASE response confirmation is sent from 
the BCF to TACF to confirm the HANDOVER CONNECTION RELEASE request 
indication. The detail is represented in Figure 496. 
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A BEARER RELEASE request indication is sent from the TACFa to TACFv to 
request to release the handover link in the network. The detail is represented in 
Figure 497. 

Another BEARER RELEASE request indication is sent from the TACF to BCF 
to request to release the handover link in the network. The detail is represented in 
Figure 498. 

A BEARER RELEASE response confirmation is sent from the BCF to TACF to 
confirm the BEARER RELEASE request indication. The detail is represented in 
Figure 499. 

A BEARER-AND-RADIO-BEARER RELEASE request indication is sent from 
the TACF to BCFr to request to release the access link or handover link between the 
BCF and BCFr and between BCAF and BCF. The detail is represented in Figure 500. 
The asterisked information element in Figure 500 us included when this information 
flow is sent from the BCFr and TACF. 

A BEARER-AND-RADIO-BEARER RELEASE response confirmation is a 
response to the BEARER-AND-RADIO-BEARER RELEASE request indication and is 
sent from the BCFr to TACF to indicate the completion of the release of the access link 
or hand over link. The detail is represented in Figure 501. 

A BEARER RELEASE response confirmation is sent from the TACFv to 
TACFa to confirm the BEARER RELEASE request indication. The detail is 
represented in Figure 502. 

2.4.3.5.7 ACCH REPLACEMENT 

Figure 790 shows a part of the invented system for describing the ACCH 
replacement. In Figure 790, a service control center 1, connected to a public network 
(not shown), controls or manages a plurality of (two in the example in Figure 790) 
mobile service switching centers 2a and 2b. Each mobile service switching center 2a 
or 2b is connected with a base station controller 3a or 3b via a plurality of lines. The 
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base station controller 3a controls base stations 6a to 6d while the base station 
controller 3b controls base stations 6e to 6h. The base stations 6a to 6h possess radio 
zones 5a to 5h, respectively, and one of the base stations is communicable with a 
mobile station 7 when the mobile station 7 visits the corresponding radio zone. 

In relation to Figure 790, assume that the mobile station 7 exists in the radio 
zone 5b and treats a plurality of calls using a plurality of traffic channels. At least 
one ACCH (associated control channel), utilizing the same radio resources as those for 
one of the traffic channels that are used for voice or data transportation, is necessary. 

As already described at section 2.2.2, one ACCH (for example, ACCH1 in 
Figure 790) is selected in accordance with the invented system, and is used for 
transporting all of the control signals involved in the mobile station 7. Therefore, it is 
possible to reduce the number of hardware elements for transporting control signals in 
comparison with the case that the calls respectively utilize multiple ACCHs. In 
addition, it is possible to exclude complicated control procedures, e.g., adjustment of 
the transportation order of control information in the plurality of ACCHs. 

In such a communications system, however, when a set of wireless 
communication resources involved in the single ACCH is released due to the release of 
one of the traffic channels by the ending of the call, it is difficult to secure the ACCH to 
continue the other call. The same problem may occur when the transmission rate in 
the ACCH is altered. Consequently, when the radio resources involved in the 
employed ACCH are released due to a connection or call release, and when another call 
should be continued, ACCH replacement is necessary. ACCH replacement is also 
necessary when altering the transmission rate in the ACCH. 

Accordingly, in addition to sharing the single ACCH by the multiple traffic 
channels for realizing the multiple calls simultaneously by the single mobile station 7, 
when the single set of wireless communication resources involved in the single ACCH 
is released, the ACCH is replaced by another ACCH. 
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2.4.3.5.7.2 INFORMATION FLOW DIAGRAM 
a) FUNCTIONAL MODEL 

Figure 52 shows functional entities involved in the ACCH replacement of the 
invented system. As shown in Figure 52, these functional entities can be categorized 
into two types: the first type is functional entities arranged in the mobile terminal and 
the second type is functional entities arranged in the visited network including base 
stations. The arrangement and the function of the functional entities will be 
described next briefly. 

The mobile communications control center 2a or 2b in Figure 790 is provided 
with a CCFa (call control function) which is a functional entity for controlling call and 
connection. The index "a" of CCFa is the abbreviation of "anchor" that means it is 
fixed at the start of communication and does not move although the mobile terminal 6 
moves. 

The base station controller 3a or 3b is provided with a TACFa (terminal access 
control function) and a BCFa (bearer control function). The TACFa is a functional 
entity for controlling the access from the network to the mobile station 7 and for 
instructing the activation and release of the ACCH. The BCFa (bearer control 
function) is a functional entity for controlling the bearer. As similar to above, the 
index "a" is the abbreviation of "anchor." 

The base station controller 3a or 3b, which may be the same as or other than 
that with the TACFa and BCFa, is provided with a TACFv and BCFv. The index V is 
the abbreviation of "visited." 

Either of the base stations 4a and 4b that are controlled by the base station 
controller with the TACFv and BCFv is provided with a BCFr (bearer control function) 
associated with radio bearers. The BCFr controls radio bearers and activates and 
releases the ACCH. 

The mobile terminal 6 is provided with a TACAF (terminal access control 
agent function) and BCAF (bearer control agent function). The TACAF is a functional 
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entity for controlling the access to the mobile terminal and for instructing the release 
and establishment of the ACCH. The BCAF is a functional entity for controlling the 
radio bearer of the mobile terminal and for executing the release and establishment of 
the ACCH. 

The index "1" or "2" is attached to the functional entities. The index "1" 
means that the corresponding entity is served for the first call while the index "2" 
means that the corresponding entity is served for the second call within a plurality of 
calls that the mobile terminal 7 is carrying out.o 

(b) INFORMATION FLOWS 

Figures 53 and 54 cooperate to form an information flow diagram showing the 
ACCH replacement procedure executed in the communication control plane. 

2.4.3.5.7.3 DEFINITIONS OF INFORMATION FLOWS AND ASSOCIATED 

INFORMATION ELEMENTS 

Information flows and information elements in Figures 53 and 54 will be 
described below and the information elements are represented in tables. With 
reference to the sequential chart in Figures 53 and 54, the ACCH replacement 
procedure will be described. 

The ACCH replacement procedure in Figures 53 and 54 is started under the 
condition described below. 

(a) Previously, a mobile station has treated first and second calls using traffic 
channels TCH1 and TCH2. 

(b) Then, the first call by the traffic channel TCH1 is now being finished. 

(c) An associated control channel ACCH1 and the traffic channel TCH1 have 
used the same radio resources. The associated control channel ACCH1 has been 
commonly shared by the first and second calls for transporting control signals. 

(d) The traffic channel TCH1 and the associated control channel ACCH1 will 
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be released due to the finish of the first call. However, it is necessary to maintain the 
second call through the traffic channel TCH2, so that another associated control 
channel is necessary. Therefore, it is necessary to replace the associated control 
channel ACCH1 by another associated control channel ACCH2 that uses the same 
5 resources as of the traffic channel TCH2. 

Consequently, the procedure illustrated in Figures 53 and 54 starts under the 
conduction, which is the same as that, under which the procedure illustrated in Figure 
262 starts. In other words, the chart shown in Figures 53 and 54 is essentially the 
same as the chart in Figure 262, but represents in more detail the replacement 

10 procedure for replacing the radio bearer between the BCAF1 and BCFrl for the first 
call with the radio bearer between the BCAF2 and BCFr2 for the second call. 

When conditions (a) to (d) are satisfied, a trigger for replacing ACCH is 
generated as represented in Figure 53. If the TACFa detects this trigger, the TACFa 
determines a connection to which the ACCH should be newly setup and then sends a 

15 HANDOVER CONNECTION SETUP request indication to the BAFa to notify of the 
handover initiation and to request to setup an ACCH. As represented in Figure 503, 
the HANDOVER CONNECTION SETUP request indication contains a BCF-TACF 
relationship ID element, base station ID element, and handover mode element. In 
the tables, "M" is the abbreviation of mandatory while "O" is the abbreviation of 

20 optional. The handover mode element in Figure 503 is mandatory when the network 
has more than one handover mode. 

As shown in Figure 53, the BCFa captures a DHT for the new ACCH, and then 
sends a HANDOVER CONNECTION SETUP response confirmation to the TACFa to 
confirm the HANDOVER CONNECTION SETUP request indication. The 

25 HANDOVER CONNECTION SETUP response confirmation contains a TACF-BCF 
relationship ID element and inter-BCF bearer ID element as represented in Figure 
504. The bearer ID element in Figure 504 identifies the bearer between the BCFa 
and BCFv. 
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Then, a BEARER SETUP request indication is sent from the TACFa to 
TACFv2, which corresponds to the second call, to setup an access bearer for the ACCH. 
The BEARER SETUP request indication contains a TACF-BCF relationship ID 
element, inter-BCF bearer ID element, base station ID element, and user information 
5 rate element as represented in Figure 505. The bearer ID element identifies the 
bearer between the BCFa and BCFv. 

The TACFv2 sets up a to-BTS short cell connection for the ACCH and then 
selects a link reference which is the same as of that the traffic channel TCH2 for 
realizing the second call. Then, the TACFv2 sends another BEARER SETUP request 

10 indication to the BCFv2. The BEARER SETUP request indication requests to setup a 
bearer for ACCH2 which is associated with the traffic channel TCH2. The BEARER 
SETUP request indication contains a TACF-BCF relationship ID element, inter-BCF 
bearer ID element, user information rate element, and base station ID element, as 
represented in Figure 506. The bearer ID element identifies the bearer between the 

15 BCFa and BCFv. 

Once the BCFv2 receives the BEARER SETUP request indication, the BCFv2 
setup the requested bearer and sends a BEARER SETUP response confirmation to the 
TACFv2 to confirm the BEARER SETUP request indication. The BEARER SETUP 
response confirmation contains a TACF-BCF relationship ID element and BCF-BCFr 

20 bearer ID element as represented in Figure 507. The bearer ID identifies the bearer 
between the BCF and BCFr. 

When the TACFv2 receives the BEARER SETUP response confirmation, 
TACFv2 sends a BEARER- AND-RADIO-BEARER SETUP request indication to the 
BCFr2 to request to setup a bearer between the BCF and BCFr and a radio bearer 

25 from the ACCH. The BEARER- AND-RADIO-BEARER SETUP request indication 
contains a TACF-BCFr relationship ID element and bearer ID element as represented 
in Figure 508. 

Upon the reception of the BEARER-AND-RADIO-BEARER SETUP request 
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indication, the BCFr2 in light of the link reference specifies the traffic channel TCH2 
and enables to start the transmission through ACCH2. Then, the BCFr2 sends a 
RADIO BEARER SETUP PROCEEDING request indication to the TACFv2 to indicate 
that the request of the radio bearer setup is accepted and that the BCFr starts setting 
up the radio bearer for ACCH2. The RADIO BEARER SETUP PROCEEDING 
request indication contains a TACF-BCFr relationship ID as represented in Figure 
509. 

Upon the reception of the RADIO BEARER SETUP PROCEEDING request 
indication, a RADIO BEARER SETUP REQUEST request indication is sent from the 
visited TACFv2, which controls the newly assigned radio bearer, to the TACFa to 
request to setup a radio bearer for ACCH2 between the mobile terminal and the BCFr 
controlled by the visited TACF. The RADIO BEARER SETUP REQUEST request 
indication contains a TACF-TACF relationship ID as represented in Figure 510. 

Next, another RADIO BEARER SETUP request indication is sent from the 
TACFa to TACAF to notify of the ACCH replacement handover execution initiation 
and to request to replace the existing physical radio channel for the first call with the 
designated physical radio channel for the ACCH. The RADIO BEARER SETUP 
request indication contains a call ID as represented in Figure 511. 

Upon the reception of the RADIO BEARER SETUP request indication, the 
TACAF as shown in Figure 54 sends BCAF2 another RADIO BEARER SETUP request 
indication.. The RADIO BEARER SETUP request indication requests to setup a radio 
bearer for the ACCH (ACCH2) and contains a TACAF-BCAF relationship ID as 
represented in Figure 512. 

Upon the reception of the RADIO BEARER SETUP request indication, the 
BCAF2 establishes the new ACCH and then sends a RADIO BEARER SETUP 
response confirmation to the TACAF to indicate the completion of the radio bearer 
setup for the new ACCH. The RADIO BEARER SETUP response confirmation 
contains a TACAF-BCAF relationship ID as represented in Figure 513. 
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Then, the TACAF sends another RADIO BEARER SETUP response 
confirmation to the TACFa to indicate the completion of setting up of the radio bearer 
for the ACCH (ACCH2). The RADIO BEARER SETUP response confirmation 
contains a TACAF-BCAF relationship ID in the same fashion as that represented in 
5 Figure 513. 

Next, the TACAF sends the BCAF1 a RADIO BEARER RELEASE request 
indication to request to release the previous radio bearer. The RADIO BEARER 
RELEASE request indication contains a TACAF-BCAF relationship ID as represented 
in Figure 514. 

10 Upon the reception of the RADIO BEARER RELEASE request indication, the 

BCAF1 releases the previously employed ACCH (ACCH1 associated with the traffic 
channel TCH1) and then replies a RADIO BEARER RELEASE response confirmation 
to the TACAF to indicate the completion of the radio bearer release. The RADIO 
BEARER RELEASE response confirmation contains a TACAF-BCAF relationship ID 

15 as represented in Figure 515. 

On the other hand, when receiving the RADIO BEARER SETUP response 
confirmation, the TACFa sends the BCFa a HANDOVER CONNECTION RELEASE 
request indication to request to remove the previous bearer in the soft handover state. 
The HANDOVER CONNECTION RELEASE request indication contains a TACF-BCF 

20 relationship ID element and released bearer ID element as represented in Figure 516. 

Upon the reception of the HANDOVER CONNECTION RELEASE request 
indication, the BCFa releases the previous DHT and sends a HANDOVER 
CONNECTION RELEASE response confirmation to the TACFa to confirm the 
HANDOVER CONNECTION RELEASE request indication. The HANDOVER 

25 CONNECTION RELEASE response confirmation contains a TACF-BCF relationship 
ID as represented in Figure 517. 

Next, the TACFa sends the TACFvl a BEARER RELEASE request indication 
to request to release the access bearer. The BEARER RELEASE request indication 
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contains a TACF-TACF relationship ID as represented in Figure 518. 

Upon the reception of the BEARER RELEASE request indication, the TACFvl 
sends the BCFvl another BEARER RELEASE request indication to request to release 
the bearer. The BEARER RELEASE request indication contains a TACF-BCF 
relationship ID as represented in Figure 519. 

Upon the reception of the BEARER RELEASE request indication, the BCFvl 
sends the TACFvl another BEARER RELEASE request indication to confirm the 
BEARER RELEASE request indication, and then release the previous resources. The 
BEARER RELEASE response confirmation contains a TACF-BCF relationship ID 
element as represented in Figure 520. 

Upon the reception of the BEARER RELEASE response confirmation, the 
TACFvl sends the BCFrl a BEARER-AND -RADIO -BEARER RELEASE request 
indication to request to release the bearer between the BCF and BCFr and the radio 
bearer. The BEARER-AND-RADIO-BEARER RELEASE request indication contains 
a TACF-BCFr relationship ID element and a cause element as represented in Figure 
521. The cause element is however included when this information element is sent 
from the BCFr to TACF. 

On the other hand, when receiving the BEARER-AND-RADIO-BEARER 
RELEASE request indication, the BCFrl stops the transmission. Then, the BCFrl 
sends the TACFvl a BEARER-AND-RADIO-BEARER RELEASE response 
confirmation and then releases the previous resources. The BEARER-AND-RADIO- 
BEARER RELEASE response confirmation is a response to the BEARER-AND- 
RADIO-BEARER request indication and indicates the completion of the release of the 
bearer and radio bearer. The BEARER-AND-RADIO-BEARER RELEASE response 
confirmation contains a TACF-BCFr relationship ID as represented in Figure 522. 

Upon the reception of the BEARER-AND-RADIO-BEARER RELEASE 
response confirmation, the TACFvl sends the TACFa a BEARER RELEASE response 
confirmation to confirm the BEARER RELEASE request indication. The BEARER 
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RELEASE response confirmation contains a TACF-TACF relationship ID as 
represented in Figure 523. 

In the above description of the ACCH replacement procedure, it is omitted to 
describe the procedure when the mobile station carries out the diversity handover for 
simplifying the description. If the mobile station 7 (refer to Figure 790) carries out 
the diversity handover, the above-mentioned functional entities (TACFvl x BCFvK 
TACFv2. BCFv2. BCFrl. BCFr2) are respectively provided with the base station 
controllers or the base stations, to which branches are established, and are controlled 
by the TACFa in the same manner as represented in Figures 53 and 54. Accordingly, 
the ACCH replacement may be executed even at the diversity handover status. In 
this case, information elements are simultaneously transported between the TACFa of 
all of the base station controllers and the TACAFv of the mobile terminal. 

In the ACCH replacement procedure, a wired access link is newly established 
between a base station controller at which the TACFa is disposed and a base station, 
and then the radio access link between the mobile terminal and the network is 
replaced. Accordingly, the ACCH replacement is accomplished. 

However, in an alteration, it is possible to replace the ACCH without the new 
establishment of the wired access link. This alteration will be described with 
reference to Figure 79 1 . 

As represented in Figure 791, a trigger for replacing ACCH is generated. If 
the TACFa detects this trigger, the TACFa determines a connection to which the 
ACCH should be newly setup; and then sends an ACCH REPLACEMENT SETUP 
request indication to the TACFv2 where the new ACCH should be setup. Upon the 
reception of the reception, the TACFv2 further sends an ACCH REPLACEMENT 
SETUP request indication to the BCFr2. As a result, the BCFr2 sets up the new 
ACCH and starts transmission through the ACCH. Then, the BCFr2 replies a 
notification of the completion of the ACCH setup to the TACFv2. Upon the reception 
of the reception of the notification, the TACFv2 sends another notification of the 
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completion of the ACCH setup to the TACFa. The TACFa sends a RADIO ACCESS 
LINK SETUP request indication as similar to the foregoing procedure represented in 
Figures 53 and 54. As a result, the BCAF2 sets up the new ACCH while the BCAF1 
releases the existent ACCH. In addition, the TACAF sends the TACFa a RADIO 
5 ACCESS LINK SET UP response confirmation. 

Upon the reception of the RADIO ACCESS LINK SETUP response 
confirmation, the TACFa sends the TACFvl an ACCH RELEASE request indication. 
Then, the TACFvl further sends the ACCH RELEASE request indication to the BCFrl. 
As a result, the BCFrl stops transmission through the existent ACCH, releases the 
io existent ACCH and sends back the TACFvl an ACCH RELEASE response 
O confirmation. Then, the TACFvl notifies the TACFa of the completion of the release 

=£ of the existent ACCH. 

12 In this procedure, since the ACCH replacement is accomplished by the 

i« functional entities illustrated in Figure 791, it is not carried out to newly set up a radio 

Ir, 15 access link in the network. 

fy 

C3 2.4.3.5.8 CODE REPLACEMENT 

2.4.3.5.8.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

20 Figure 55 shows the functional model of a part of the invented system for 

describing a code replacement. 

b) INFORMATION FLOWS 

Figure 56 shows an information flow diagram of the code replacement 
executed in the communication control plane. 



2.4.3.5.8.3 DEFINITIONS OF INFORMATION FLOWS AND ASSOCIATED 

INFORMATION ELEMENTS 
Information flows and information elements in Figure 56 will be described 
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below and the information elements are represented in tables. 

A CODE REPLACEMENT request indication is sent from a BCFr to a TACF 
to request change of codes. The detail of the CODE REPLACEMENT request 
indication is represented in Figure 524. 

Another CODE REPLACEMENT request indication is sent from the visited 
TACF to a TACFa to request change of codes. The detail of the CODE 
REPLACEMENT request indication is represented in Figure 525. 

Another CODE REPLACEMENT request indication is sent from the TACF to 
a TACAF to request change of codes. The detail of the CODE REPLACEMENT 
request indication is represented in Figure 526. The element marked by *1 in Figure 
526 may be repeated a plurality of times, the number of repetition is the same as the 
number of the handover branches related to the terminal. The element marked by *2 
in Figure 526 may be repeated a plurality of times, the number of repetition is the 
same as the number of calls related to the TACF. 

Another CODE REPLACEMENT request indication is sent from the TACAF 
to the BCAF to request to change of codes. The detail of the CODE REPLACEMENT 
request indication is represented in Figure 527. 

A CODE REPLACEMENT response confirmation is a response to the CODE 
REPLACEMENT request indication and is sent from the BCAF to the TACAF to 
indicate the completion of the change of codes. The detail of the CODE 
REPLACEMENT response confirmation is represented in Figure 528. 

Another CODE REPLACEMENT response confirmation is a response to the 
CODE REPLACEMENT request indication and is sent from the TACAF to the TACFa 
to confirm the CODE REPLACEMENT request indication. The detail of the CODE 
REPLACEMENT response confirmation is represented in Figure 529. 

Another CODE REPLACEMENT response confirmation is sent from the 
TACFa to the TACFv to confirm the CODE REPLACEMENT request indication. The 
detail of the CODE REPLACEMENT response confirmation is represented in Figure 
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530. 

Another CODE REPLACEMENT response confirmation is sent from the 
TACF to the BCFr to confirm the CODE REPLACEMENT request indication. The 
detail of the CODE REPLACEMENT response confirmation is represented in Figure 
531. 

2.4.3.6 TRANSMISSION POWER CONTROL 

2.4.3.6.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

Figure 57 shows the functional model of a part of the invented system for 
describing a transmission power control. 

b) INFORMATION FLOWS 

Figure 58 shows an information flow diagram of the transmission power 
control executed in the communication control plane. 

2.4.3.6.3 DEFINITIONS OF INFORMATION FLOWS AND ASSOCIATED 
INFORMATION ELEMENTS 

Information flows and information elements in Figure 58 will be described 
below and the information elements are represented in tables. 

A CELL CONDITION REPORT request indication is sent from an MRRC to 
an RRC periodically to notify of the radio conditions of respective handover branches. 
The detail of the CELL CONDITION REPORT request indication is represented in 
Figure 532. 

A TRANSMISSION POWER CONTROL request indication is sent from a 
TACFa to TACFv to notify of the instructed transmission power. The detail of the 
TRANSMISSION POWER CONTROL request indication is represented in Figure 533. 

Another TRANSMISSION POWER CONTROL request indication is sent from 
a TACFv to BCFr to notify of the instructed transmission power. The detail of the 
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TRANSMISSION POWER CONTROL request indication is represented in Figure 534. 



2.4.4 INFORMATION FLOWS OF MOBILITY SERVICES 

2.4.4.1 TERMINAL LOCATION UPDATING 

5 2.4.4.1.1 COMMON PROCEDURE MODULES USED 

Common procedure modules used within the terminal location updating 
service are the TMUI inquiry, the FPLMTS user ID retrieval, the user authentication 
procedure, the ciphering start time notification, and the TMUI assignment. 

10 2.4.4.1.2 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

Figure 59 shows the functional model of a part of the invented system for 
describing a terminal location updating. 

b) INFORMATION FLOWS 

15 Figures GO and 61 form an information flow diagram of the terminal location 

updating. 

2.4.4.1.3 DEFINITIONS OF INFORMATION FLOWS AND ASSOCIATED 

INFORMATION ELEMENTS 
20 Information flow in Figures 60 and 61 will be described below and information 

elements of the flows are represented in tables. 



Relationship rd (LRCF-LRDF) 

An LAI UPDATE request indication is sent from the visited SCF to the SDF 
25 for requesting to update the location area information. A response confirmation is 
returned to the visited SCF from the SDF to confirm the completion of updating the 
location area information. Figure 535 represents the details of the LAI UPDATE 
request indication and the LAI UPDATE response confirmation. 
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Relationship rk (SACF-LRCF) 

A TERMINAL LOCATION UPDATE request indication is sent from the SACF 
to the visited SCF for requesting to update the location information of the mobile 
terminal. A response confirmation is returned to the SACF from the visited SCF to 
5 confirm the completion of updating the terminal location information. Figure 536 
represents the details of the TERMINAL LOCATION UPDATE request indication and 
the TERMINAL LOCATION UPDATE response confirmation. 

Relationship rl (MCF-SACF) 

Another TERMINAL LOCATION UPDATE request indication is sent from the 
10 MCF to the SACF for requesting to update the location information of the mobile 
terminal. A response confirmation is returned to the MCF from the SACF to confirm 
the completion of updating the terminal location information. Figure 537 represents 
the details of the TERMINAL LOCATION UPDATE request indication and the 
TERMINAL LOCATION UPDATE response confirmation. 
15 [Notes} 

1) The relationship ID element identifies the relationship between requests and 
responses. 

2) TMUI and TMUI assignment source ID should be used for the FPLMTS user 
ID element for relationships rl and rk. 

20 3) The terminal status element indicates whether the terminal can accept a call 
or not. 

4) The TC information is a terminal data information which indicates terminal 
capabilities. 

25 2.4.5 INFORMATION FLOWS OF SECURITY SERVICES 

2.4.5.1 USER AUTHENTICATION 

a) FUNCTIONAL MODEL 

Figure 62 shows the functional model of a part of the invented system for 
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describing a user authentication. 

b) INFORMATION FLOWS 

Figure 63 shows an information flow diagram of the user authentication. 

c) DEFINITIONS OF INFORMATION FLOWS, INFORMATION 
ELEMENTS, AND FUNCTIONAL ENTITY ACTIONS 

Information flows and functional entity actions in Figure 63 will be described 
below and information elements of the flows are represented in tables. 
Relationship rd (LRCF-LRDF) 

An authentication information retrieval information flow is used to request 
the security information from the visited LRDF for the user authentication. Figure 
538 represents the detail of the AUTHENTICATION INFORMATION RETRIEVAL 
request indication and the AUTHENTICATION INFORMATION RETRIEVAL 
response confirmation. 

Relationship rg (LRCF-TACF) and Relationship rk(LRCF-SACF) 
An AUTHENTICATION CHALLENGE IF is used to verify the identity of the 
user. That is, an authentication challenge initiated by a network is sent from LRCF 
to TACF/SACF for requesting the return of the authentication calculation result. 
Figure 539 represents the detail of the AUTHENTICATION CHALLENGE request 
indication and the AUTHENTICATION CHALLENGE response confirmation. 
Relationship rb (TACFF-TACAF) and Relationship rl (SACF-MCF) 
Another AUTHENTICATION CHALLENGE IF is used to verify the identity 
of the user. That is, an authentication challenge initiated by the network is sent from 
TACFF to TACAF and from SACF to MCF for requesting the return of the 
authentication calculation result. Figure 540 represents the detail of the 
AUTHENTICATION CHALLENGE request indication and the AUTHENTICATION 
CHALLENGE response confirmation. 

Relationship rv(UIMF-TACAF) and Relationship ry (UIMF-MCF) 

An AUTHENTICATION request indication is used to send a random number 



F0220/2551 




197 

and to request to calculate a response with the random number and authentication key 
retained in the UIMR An AUTHENTICATION response confirmation is used to send 
the authentication calculation result. Figure 541 represents the detail of the 
AUTHENTICATION request indication and the AUTHENTICATION response 
confirmation. 

2.4.5.2 CIPHERING START TIME NOTIFICATION 

2.4.5.2.1 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

Figure 64 shows the functional model of a part of the invented system for 
describing a ciphering start time notification. 

b) INFORMATION FLOWS 

Figure 65 shows an information flow diagram of the ciphering start time 
notification. 

c) DEFINITIONS OF INFORMATION FLOWS, INFORMATION 
ELEMENTS, AND FUNCTIONAL ENTITY ACTIONS 

Information flows and functional entity actions in Figure 65 will be described 
below and information elements of the flows are represented in tables. 
Relationship rb (TACF-TACAF) 

A START CIPHERING request indication is used to request that the terminal 
begins to apply the encryption procedure to information transmitted between itself 
and the network. This needs a confirming information flow. 

Relationship rg (LRCF-TACF) 

Another START CIPHERING request indication is used to request that the 
terminal begins to apply the encryption procedure to information transmitted between 
itself and the network. This needs a confirming information flow. Figure 542 
represents the details of the START CIPHERING request indication and the START 
CIPHERING response confirmation. 



F0220/2551 



198 

Relationship rk (LRCF-SACF) 
x Another START CIPHERING request indication is used to request that the 
terminal begins to apply the encryption procedure to information transmitted between 
itself and the network. This needs a confirming information flow. Figure 543 
represents the details of the START CIPHERING request indication and the START 
CIPHERING response confirmation. 

Relationship rl (SACF-MCF) 

Another START CIPHERING request indication is used to request that the 
terminal begins to apply the encryption procedure to information transmitted between 
itself and the network. This needs a confirming information flow. 

2.4.5.3. TMUI MANAGEMENT AND USER ID RETRIEVAL 

2.4.5.3.1 TMUI ASSIGNMENT 

2.4.5.3.1.1 INFORMATION FLOW DIAGRAM 

a) FUNCTIONAL MODEL 

Figure 66 shows the functional model of a part of the invented system for 
describing a TMUI assignment. 

b) INFORMATION FLOWS 

Figure 67 shows an information flow diagram of the TMUI assignment. In 
Figure 67, the relationship between MCF and SACF is used for the user 
authentication in non-call related case while the relationship between TACAF and 
TACF is used for the user authentication in call related case. However, this could be 
accommodated with the relationship between MCF and SACF as well. An 
AUTHENTICATION INFORMATION RETRIEVAL request indication and an 
AUTHENTICATION INFORMATION response confirmation are used if no user 
authentication information is available in the visited network. 

c) DEFINITIONS OF INFORMATION FLOWS, INFORMATION 
ELEMENTS, AND FUNCTIONAL ENTITY ACTIONS 
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Information flows and functional entity actions in Figure 67 will be described 
below and information elements of the flows are represented in tables. 
Relationship rb (TACF-TACAF) 

A TMUI ASSIGNMENT request indication is used to assign and convey the 
TMUI to the user after the network has verified the identity of the user. A response 
confirmation is returned for acknowledging the successful assignment of the TMUI. 
Figure 544 represents the details of the TMUI ASSIGNMENT request indication and 
the response confirmation. 

Relationship rd (LRCF-LRDF) 

A TMUI QUERY IF is used to request a new TMUI available from the visited 
LRDF. Figure 545 represents the details of the TMUI QUERY request indication and 
response confirmation. 

A TMUI MODIFY request indication is used to request the visited LRDF to 
modify the TMUI information for the user. Then, a confirmation is sent after it has 
been modified. Figure 546 represents the details of the TMUI MODIFY request 
indication and response confirmation. 

Relationship rg (LRCF-TACF) 

Another TMUI ASSIGNMENT request indication is used to assign and convey 
the TMUI to the user after the network has verified the identity of the user. A 
response confirmation is returned for acknowledging the successful assignment of the 
TMUI. Figure 547 represents the details of the TMUI ASSIGNMENT request 
indication and the response confirmation. 

Relationship rk (LRCF-SACF) 

Another TMUI ASSIGNMENT request indication is used to assign and convey 
the TMUI to the user after the network has verified the identity of the user. A 
response confirmation is returned for acknowledging the successful assignment of the 
TMUI. Figure 548 represents the details of the TMUI ASSIGNMENT request 
indication and the response confirmation. 
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Relationship rl (SACF-MCF) 

Another TMUI ASSIGNMENT request indication is used to assign and convey 
the TMUI to the user after the network has verified the identity of the user. A 
response confirmation is returned for acknowledging the successful assignment of the 
TMUI. Figure 549 represents the details of the TMUI ASSIGNMENT request 
indication and the response confirmation. 

2.4.5.3.2 USER ID RETRIEVAL 

This procedure is used to convert the TMUI to the IMUI of an FPLMTS user. 
This procedure is initiated by the newly visited network when the network receives the 
TMUI or a set of TMUI and TMUI assignment source ID as the FPLMTS user ID from 
the mobile terminal. When newly visited LRCF receives the TMUI or a set of TMUI 
and TMUI assignment source ID from the mobile terminal, the LRCF should analyze 
which procedure (selected from the following procedures) would be executed. 

1) Terminal Location Registration and Update 

Case A) TMUI has been assigned by the newly visited LRDF. 
Case B) TMUI has been assigned by another LRDF. 
In this rule, case B is not described. 

2) Mobile Originating Call 

3) Unsuccessful Case: If the newly visited network cannot retrieve successfully (e.g., 
loses TMUI), then the newly visited network attempts to retrieve the FPLMTS user's 
IMUI from the UIMF. 

2.4.5.3.2.1 INFORMATION FLOW DIAGRAM 

Figure 68 shows an information flow diagram of the user ID retrieval. 

2.4.5.3.2.2 INFORMATION FLOWS AND ASSOCIATED INFORMATION 
ELEMENTS 

Relationship rd (LRCF-LRDF) 
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An IMUI RETRIEVAL request indication is used to retrieve an IMUI on the 
basis of its corresponding TMUI. This information flow is sent from the LRCF to the 
LRDF in the - same network. An IMUI RETRIEVAL response confirmation is a 
response to the request indication. The details of the IMUI RETRIEVAL request 
indication and response confirmation are represented in Figure 550. In case that a 
call is originated from the mobile terminal, the TMUI assignment source ID element in 
Figure 550 is not included. 

Relationship rl (SACF-LRCF) 

Another IMUI RETRIEVAL request indication is used to retrieve the IMUI 
from the mobile terminal. This information flow is used only when the network does 
not convert the TMUI of the FPLMT user into the IMUI. This information flow is 
sent from the SCF to the SACF in the visited network. An IMUI RETRIEVAL 
response confirmation is a response to the request. The details of the IMUI 
RETRIEVAL request indication and response confirmation are represented in Figure 
551. 

Relationship rk (MCF-SACF) 

Another IMUI RETRIEVAL request indication is used to retrieve the IMUI 
from the mobile terminal. This information flow is used only when the network does 
not convert the TMUI of the FPLMT user into the IMUI. This information flow is 
sent from the SACF to the MCF in the visited network. An IMUI RETRIEVAL 
response confirmation is a response to the request. The details of the IMUI 
RETRIEVAL request indication and response confirmation are represented in Figure 
552. 

Relationship rg (TACF-LRCF) 

Another IMUI RETRIEVAL request indication is used to retrieve the IMUI 
from the mobile terminal. This information flow is used only when the network does 
not convert the TMUI of the FPLMT user into the IMUI. This information flow is 
sent from the LRCF to the TACF in the visited network. An IMUI RETRIEVAL 
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response confirmation is a response to the request. The details of the IMUI 
RETRIEVAL request indication and response confirmation are represented in Figure 
553. 

Relationship rb (TACAF-TACF) 

Another IMUI RETRIEVAL request indication is used to retrieve, the IMUI 
from the mobile terminal. This information flow is used only when the network does 
not convert the TMUI of the FPLMT user into the IMUI. This information flow is 
sent from the TACF to the TACAF in the visited network. An IMUI RETRIEVAL 
response confirmation is a response to the request. The details of the IMUI 
RETRIEVAL request indication and response confirmation are represented in Figure 
554. 

2.4.6 SDL DIAGRAMS 

SDL diagrams for functional entities (Figures 254 to 258) complies with IMT- 
2000 Recommendation Draft Q.FIF. Scenario 3 in the access link setup procedure, 
however, shall not be applied in this document. The number attached in the texts on 
the information flow transmission/reception between FEs in the SDL diagrams 
indicates the FEA number in the ITU Recommendation Draft Q.FIF. 

2.5 PROTOCOL SPECIFICATIONS 

2.5.1 REFERENCE CONFIGURATION 

The correlation between physical node configuration and functional entities in 
the invented system is represented in Figure 69. The system is provided with radio 
interfaces and BTS-MCC interfaces to specify the protocol. 



2.5.2 
2.5.2.1 



RADIO INTERFACE SPECIFICATION 
GENERAL 

Section 2.5.2 describes layer 1-3 protocol specifications for the radio interface. 
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2.5.2.2 



LAYER 1 



The description in connection with layer 1 protocol is omitted. 



2.5.2.3 



LAYER 2 



2.5.2.3.1 



GENERAL 



Layer 2 consists of a LAC (link access control) sub -layer and a MAC (medium 
access control) sub-layer. The LAC sub-layer consists of a layer-3-coordination sub- 
sub-layer and an LLC (logical link control) sub-sub -layer. Figure 70 shows the 
signaling layer 2 protocol architecture over the radio interface. Figure 71 shows a 
sample frame structure for the BSC function termination. 



The LAC transfers variable length service data units (SDUs) between users 
at layer 2 with high reliability. 

2.5.2.3.1.1.1 LAYER-3-COORDINATION SUB-SUB-LAYER 

The layer-3-coordination sub-sub-layer performs primitive/parameter 
mapping between LLC and layer 3, and disassembles/assembles a layer data unit 
to/from LLC SDUs. 

2.5.2.3.1.1.2 LLC (LOGICAL LINK CONTROL) SUB-SUB-LAYER 

The LLC sub -sub -layer offers a high-reliability transfer function using error 
control, flow control, and so on. 



2.5.2.3.1.1 



LAC (LINK ACCESS CONTROL) SUB-LAYER 



2.5.2.3. 1.2 MAC (MEDIUM ACCESS CONTROL) SUB-LAYER 

The MAC sub -layer detects an error of LLC 
disassembles/assembles an LLC PDU to/from layer 1 frames. 



PDUs and 
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2.5.2.3.2 FUNCTIONS 

2.5.2.3.2. 1 FUNCTIONS OF LAC (LINK ACCESS CONTROL) SUB-LAYER 

2.5.2.3.2.1.1 LAYER-3-COORDINATION SUB-SUB-LAYER 

a) SIGNALING LAYER 3 PDU ASSEMBLY AND DISASSEMBLY 

This function provides for assembling a signaling layer 3 data unit from LLC 
PDUs and for disassembling a signaling layer 3 PDU to LLC PDUs. 

b) LINK CONTROL 

This function specifies the layer 3 entity which should process the LAC SDU 
with the SAPI. The application should be studied further. 

c) CODE TYPE IDENTIFICATION 

This function identifies the code type when adopting the hybrid ARQ. 

2.5.2.3.2. 1.2 LLC (LOGICAL LINK CONTROL) SUB-SUB-LAYER 

a) SEQUENCE INTEGRITY 

This function preserves the order of LLC SDUs that were submitted for 
transfer by this layer. 

b) ERROR CORRECTION BY SELECTIVE RETRANSMISSION 

Through a sequencing mechanism, the receiving LLC entity can detect 
missing LLC SDUs. This function corrects the sequence errors by means of 
retransmission. 

c) FLOW CONTROL 

This function allows an LLC receiver to control the rate at which a peer LLC 
transmitter entity may send information. 

d) ERROR REPORTING TO LAYER MANAGEMENT 

This function indicates to layer management errors which have occurred. 

e) KEEP ALIVE 

This function verifies that two peer LLC entities participating in a link are 
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remaining in a link connection established state even in the case of a prolonged 
absence of data transfer. 

f) LOCAL DATA RETRIEVAL 

This function allows the local LLC user to retrieve in-sequence SDUs which 
5 have not yet been released by the LLC entity. 

g) CONNECTION CONTROL 

This function performs the establishment, release, and resynchronization of 
an LLC link. It also allows the transmission of variable length user-to-user 
information without a guarantee of delivery. 
10 h) TRANSFER OF USER-DATA 

This function is used for the conveyance of user data between users of the LLC. 
LLC supports both assured and unassured data transfer, 
i) PROTOCOL ERROR DETECTION AND RECOVERY 

This function detects errors and recovers from errors in the operation of the 

15 protocol. 

j) STATUS REPORTING 

This function allows a transmitter peer entity and a receiver peer entity to 
exchange status information. 

20 2.5.2.3.2.2 FUNCTIONS OF MAC (MEDIUM ACCESS CONTROL) SUB-LAYER 

a) CRC ERROR DETECTION AND HANDLING 

This function provides for detecting and handling LLC PDU corruption by 
means of CRC. Corrupted LLC PDUs are discarded. 

b) ASSEMBLY AND DISASSEMBLY OF LLC PDU OR BTS LAYER 3 PDU 
25 FROM/TO LAYER 1 FRAMES 

This function provides for assembling an LLC PDU or BTS layer 3 PDU from 
layer 1 frames and for disassembling an LLC PDU or BTS layer 3 PDU to layer 1 
frames. 
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This function includes the padding function to extend the length of the MAC 
PDU to an integer multiple of the length of layer 1 frames. Before transferring 
through the RACH, a sequence number should be attached in order to prevent the 
MAC PDU from being received twice. 

c) ADDRESS CONTROL 

This function identifies the logical link in the RACH/FACH, e.g., for respective 
mobile terminals, using a personal identity system. 

d) IDENTITY OF SIGNAL CONTENT 

This function classifies information, transmitted over the RACH, FACH, and 
UPCH, into user information or control information. 

e) IDENTITY OF TERMINATING NODE 

This function classifies nodes, where signals are terminated, into the BTS function 
node and the BSC function node. 

2.5.2.3.3 FORMATS AND PARAMETERS OF DATA UNITS 

2.5.2.3.3.1 FORMAT AND PARAMETERS OF PDUs IN LAC SUB-LAYER 

2.5.2.3.3.1.1 LAYER 3 COMPATIBLE SUB-SUB-LAYER PDU 

a) SAPI (SERVICE ACCESS POINT IDENTIFIER) 

This indicates to layer 3 the type of service provided by layer 2. This 
parameter is represented in Figure 555. 

b) ST 

This parameter is attached to layer 3 compatible sub-sub-layer PDUs when 
disassembling a layer 3 PDU to those. This parameter is referred for future 
assembling a layer 3 PDU estimation from those in the correct order. This parameter 
is represented in Figure 556. 

c) CODE TYPE INDICATOR 

This parameter indicates the type of code to adopt the hybrid ARQ. The 
adoption shall depend on the version. This parameter is represented in Figure 557. 
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d) RESERVED PARAMETER 

This parameter indicates the version of layer-3-coordination sub -sub -layer, 
and so on. This parameter is represented in Figure 558. 

2.5.2.3.3.1.2 LLCPDUs 
2.5.2.3.3.1.2.1 TYPES OF LLC PDUs 

Various types of LLC protocol data units (PDUs) are listed in Figures 559 and 
560. Definitions of the types of LLC PDUs will be described below, 
a) BGN PDU (BEGIN) 

The BGN PDU is used to establish an LLC link between two peer entities. 
The BGN PDU requests to clear peer's transmitter and receiver buffers, and to 
initialize peer's transmitter and receiver state variables. 

b) BGAK PDU (BEGIN ACKNOWLEDGE) 

The BGAK PDU is used to acknowledge the acceptance of a layer 2 link setup 
request from a peer. 

c) BGREJ PDU (BEGIN REJECT) 

The BGREJ PDU is used to reject the layer 2 link setup request of the peer 
LLC entity. 

d) END PDU (END) 

The END PDU is used to release an LLC link between two peer entities. 

e) ENDAK PDU (END ACKNOWLEDGE) 

The ENDAK PDU is used to acknowledge the release of an LLC link. 

f) RS PDU (Resynchronization) 

The RS PDU is used to resynchronize the buffers and data transfer state 
variables. 

g) RSAK PDU (RESYNCHRONIZATION ACKNOWLEDGE) 

The RSAK PDU is used to acknowledge the acceptance of a resynchronization 
requested by the peer LLC entity. 
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h) ER PDU (ERROR RECOVERY) 

The ER PDU is used to recover from protocol error. 

i) ERAK PDU (ERROR RECOVERY ACKNOWLEDGE) 

The ERAK PDU is used to acknowledge the recovery from protocol error. 
5 j) SD PDU (SEQUENCED DATA) 

The SD PDU is used to transfer, through an LLC link, sequentially numbered 
PDUs containing information fields provided by the LLC user, 
k) POLL PDU (STATUS REQUEST) 

The POLL PDU is used to request, across an LLC link, to transmit status 
10 information about the peer LLC entity. 

1) STAT PDU (SOLICITED STATES RESPONSE) 

The STAT PDU is used to respond to a status request (POLL PDU) received 
from a peer LLC entity. It contains information regarding the reception status of SD 
PDUs and SD-with-POLL PDUs in the N(R) field, credit information for the peer 
15 transmitter in the N(MR) field, and the sequence number in the N(PS) field 
corresponding to the POLL PDU or SD-with-POLL PDU to which it is in response, 
m) USTAT PDU (UNSOLICITED STATES RESPONSE) 

The USTAT PDU is used to respond to a detection of one or more new missing 
SD PDUs, based on the examination of the sequence number of the SD PDU. It 
20 contains information regarding the reception status of SD PDUs in the N(R) field, and 
an upper-window-edge information for the peer transmitter in the N(MR) field, 
n) SD-with-POLL PDU (SEQUENCED DATA WITH STATUS REQUEST) 

The SD-with-POLL PDU is used to transfer, through an LLC link, 
sequentially numbered PDUs containing information fields provided by the LLC user 
25 and used to request status information about the peer LLC entity, 
o) UD PDU (UNNUMBERED DATA PDU) 

The UD PDU is used for unassured data transfer between two LLC users. 
When an LLC user requests unacknowledged information transfer, the UD PDU is 
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used to send information to the peer without affecting LLC states or variables. The 
UD PDUs does not carry a sequence number and therefore, the UD PDU may be lost 
without notification. 

p) MD PDU (MANAGEMENT DATA PDU) 
5 The MD PDU is used for transferring unassured management data between 

two management entities. When a management entity requests unacknowledged 
information transfer, the MD PDU is used to send information to the peer 
management entity without affecting LLC states or variables. The MD PDU does not 
carry a sequence number and therefore, the MD PDU may be lost without notification. 
10 An invalid PDU is a PDU which: 

a) has an unknown PDU type code, or 

b) is not of the proper length of the PDU belonging to the stated types. 
Invalid PDUs shall be discarded without notification to the sender. No 

additional action is taken as a result of the invalid PDU. Length violations from 
15 items b) and c) above are reported to layer management. 

2.5.2.3.3.1.2.2 FORMATS OF LLC PDUs 

Figures 72 through 88 represents formats of LLC PDUs. As listed at section 
2.5.2.3.3.1.2.1, there are 16 types of PDUs. 

20 Figure 72 represents the sequenced data PDU (SD PDU). Figure 73 

represents the sequenced-data-with-status-request PDU (SD-with-POLL PDU). 
Figure 74 represents the POLL PDU. Figure 75 represents the STAT PDU. Figure 
76 represents the USTAT PDU. Figure 77 represents the UD PDU and MD PDU. 
Figure 78 represents the Begin PDU (BGN PDU). Figure 79 represents the BGAK 

25 PDU. Figure 80 represents the BGREJ PDU. Figure 81 represents the END PDU. 
Figure 82 represents the ENDAK PDU. Figure 83 represents the RS PDU. Figure 
84 represents the RSAK PDU. Figure. 85 represents the ER PDU. Figure 86 
represents the ERAK PDU. Features of these formats will be described below. 
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2.5.2.3.3.1.2.2.1 CODING CONVENTIONS 

The coding of the LLC PDU conforms to the coding conventions specified in 
2.1/1.361 [4], LLC PDU is trailer oriented: i.e., the protocol control information is 
5 transmitted last. 

2.5.2.3.3.1.2.2.2 RESERVED FIELD 

There is a field of reserved bits (that may be refried to as R, Rsvd, Reserved) in 
each PDU. One function of the reserved field is to achieve the eight-bit alignment of 
10 PDU. Other functions should be studied further. When no functions other than the 
eight-bit-alignment are defined, this field shall be coded as zero. This field shall be 
ignored by the receiver. 

2.5.2.3.3.1.2.2.3 PDU length 

15 The maximum length of the information fields in SD, UD, and MD PDUs is k 

octets. The maximum value of k should be studied further. The value of k is 
determined at part of size negotiation procedures carried out outside LLC, upon 
bilateral agreement, and may be specified by another Recommendation utilizing LLC, 
or may be derived from the maximum length PDU size for protocols using LLC. The 

20 minimum value of k is 0 octets. 

The maximum length of a variable length SSCOP-UU field is j octets. The 
maximum value of j should be studied further. The value of j is determined upon 
bilateral agreement, may be specified by another Recommendation utilizing LLC, or 
may be derived from requirements of protocols utilizing LLC. The minimum value of 

25 j is 0 octets. 



2.5.2.3.3.1.2.2.4 CODINGS OF STAT AND USTAT PDU 

Each USTAT PDU contains two list elements. Each STAT PDU contains zero 
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5 



i| 10 
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20 



25 



or more list elements. Transmitted STAT messages may be segmented into two or 
more STAT PDUs. 

The processing of a STAT PDU does not rely on information in other STAT 
PDUs. This is true even for the case when multiple STAT PDUs are generated in 
response to a single POLL PDU, and one or more of these PDUs are lost. 

The span list items in the STAT and USTAT PDUs are odd or even elements of 
a list used for selective retransmission requests. Every odd element represents the 
first PDU of a missing gap, and every even element, except possibly the last one, 
represents the first PDU of a received sequence. 

2.5.2.3.3.1.2.2.5 STATES OF LLC PROTOCOL ENTITY 

This sub-clause describes the states of an LLC entity. These states are used 
in the specification of the peer-to-peer protocol. The states are conceptual and reflect 
general conditions of the LLC entity in the sequences of signals and PDU exchanges 
with its user and peer, respectively. In addition, other conditions are used in the 
description, in order to avoid identification of additional states, as detailed in the SDLs. 
The basic states will be described below. 

State 1 (Idle) 

Each LLC entity is conceptually initiated in an Idle state (state 1) and returns 
to this state upon the release of a connection. 

State 2 (Outgoing Connection Pending) 

An LLC entity requesting a connection with a peer is in an outgoing 
connection pending state (state 2) until it receives an acknowledgement from the peer. 
State 3 (Incoming Connection Pending) 

An LLC entity that has received a connection request from a peer and is 
waiting for its user's response is in an incoming connection pending (state 3). 



State 4 (Outgoing Disconnection Pending) 

An LLC entity requesting release of the peer-to-peer connection is in an 
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outgoing disconnection pending state (state 4) until it receives a confirmation that the 
peer entity has released and transitioned to the Idle state (State 1). 
State 5 (Outgoing Resynchronization Pending) 

An LLC entity requesting resynchronization of the connection with a peer is in 
5 an outgoing resynchronization pending state (state 5). 

State 6 (Incoming Resynchronization Pending) 

An LLC entity that has received a resynchronization request from a peer and 
is waiting for its user's response is in an incoming resynchronization pending state 
(state 5). 

10 State 7 (Outgoing Recovery Pending) 

An LLC entity requesting recovery of an existing connection with a peer is in 
an outgoing recovery pending state (state 7). 

State 8 (Recovery Response Pending) 

An LLC entity that has completed recovery, notified its user of the recovery 
15 completion, and is awaiting for a response from the user is in a recovery response 
pending state (state 8). 

State 9 (Incoming Recovery Pending) 

An LLC entity that has received a recovery request from a peer and is waiting 
for its user's response is in an incoming recovery pending state (state 9). 
20 State 10 (Data Transfer Ready) 

Upon successful completion of the connection establishment, 
resynchronization, or error recovery procedures, both peer LLC entities will be in a 
data transfer ready state (state 10) and possible to execute data transfer. 

25 2.5.2.3.3.1.2,4 LLC STATE VARIABLES 

This section describes the state variables used in the peer-to-peer protocol. 
SD and POLL PDUs are sequentially and independently numbered, and may have a 
value between "0" and n minus 1 (where n is the modulus of the sequence number). 
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The modulus equals to 2 8 , and therefore, the sequence number cycles through the 
entire range between 0 through 2 8 - 1. Therefore, all arithmetic operations on the 
following state variables or sequence numbers are affected by the modulus: VT(S), 
VT(PS), VT(A), VT(PA), VT(MS), VR(R), VR(H), and VR(MR). When performing 
5 arithmetic comparisons of transmitter variables, VT(A) is assumed as a base. When 
performing arithmetic comparisons of receiver variables, VR(R) is assumed as a base. 
In addition, the state variables VT(SQ) and VR(SQ) use the modulo 256 arithmetic. 
The LLC sub-sub-layer manages the following state variables at the transmitter. 

a) VT(S) - SENDING STATE VARIABLE 

10 This is the sequence number of an SD PDU to be transmitted next in the first 

transmission (i.e.. except for that in retransmissions). This is incremented after 
sending each SD PDU in the first transmission (i.e. except in retransmissions). 

b) VT(PS) - POLL SENDING STATE VARIABLE 

This is the sequence number of a POLL PDU or SD-with-POLL PDU 
15 transmitted currently. This is incremented before transmission of the next POLL or 
SD-with-POLL PDU. 

c) VT(A) - ACKNOWLEDGEMENT STATE VARIABLE 

This is the sequence number of an in-sequence SD PDU which is expected to 
be acknowledged next and forms the lower edge of an acknowledgement window 
20 acknowledging SD PDUs. The variable VT(A) is updated in response to the 
acknowledgement of transmitted SD PDUs. 

d) VT(PA) - POLL ACKNOWLEDGEMENT STATE VARIABLE 

This is the sequence number of an STAT PDU which is expected to be received 
next and forms the lower edge of the acknowledgement window constituted of STAT 
25 PDUs. If an STAT PDU containing an invalid parameter at the N(PS) field is 
received, a recovery is initiated or release is performed. Otherwise, if an acceptable 
STAT PDU is received, the variable VT(PA) is updated on the basis of the parameter at 
the N(PS) field of the received STAT PDU. 
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e) VT(MS) - MAXIMUM SENDABLE VALUE STATE VARIABLE 

This is the sequence number of an SD PDU which is not allowed by the peer 
receiver. That is, the peer receiver sequentially receives SD PDUs having sequence 
numbers up to VT(MS) - 1. The variable VT(MS) represents the upper edge of the 
transmission window. The transmitter should not transmit a new SD PDU if the 
current VT(S) reaches VT(MS). The variable VT(MS) is updated in response to the 
reception of a USTAT PDU, STAT PDU, BGN PDU, BGAK PDU, RS PDU, RSAK PDU, 
ER PDU, or ERAK PDU. 

f) VT(PD) - POLL DATA STATE VARIABLE 

When acknowledgements are outstanding, this state variable represents the 
number of SD PDUs transmitted between transmissions of two POLL PDUs, or the 
number of SD PDUs transmitted before the transmission of the first POLL PDU after 
a POLL timer became active. The variable VT(PD) is incremented in response to the 
transmission of an SD PDU, and reset to zero in response to the transmission of a 
POLL PDU. 

g) VT(CC) - CONNECTION CONTROL STATE VARIABLE 

This variable represents the number of unacknowledged BGN, END, ER, or 
RS PDUs. The variable VT(CC) is incremented in response to the transmission of a 
BGN, END, ER, or RS PDU. If an END PDU is transmitted in response to a protocol 
error, LLC sub-sub-layer does not wait for receiving the corresponding ENDAK PDU 
and enters directly into state 1 (Idle) and the variable VT(CC) is not incremented 

h) VT(SQ) - TRANSMITTER CONNECTION SEQUENCE STATE VARIABLE 
This state variable is used to allow the receiver to identify retransmitted BGN, 

ER, and RS PDUs. This state variable is initialized to "0" in response to creation of 
the LLC process and incremented and then mapped into the N(SQ) field of a BGN, RS, 
or ER PDU before the initial transmission of the BGN, RS, or ER PDU as represented 
in Figures 78, 83 and 85. 

Additionally, the LLC sub-sub-layer manages the following state variables at 
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the receiver. 

a) VR(R) - RECEPTION STATE VARIABLE 

This state variable is the sequence number of an in-sequence SD PDU 
expected to be received next. This variable is incremented in response to the 
reception of the next SD PDU. 

b) VR(H) - HIGHEST EXPECTED RECEPTION STATE VARIABLE 

This state variable is the highest number among sequence numbers of in- 
sequence SD PDUs in a transmission window expected to be received next. The 
variable VR(H) may be updated in response to the reception of a new SD PDU or in 
response to the reception of a POLL PDU. 

c) VR(MR) - MAXIMUM RECEIVABLE VALUE STATE VARIABLE 

This is the sequence number of an SD PDU which is not allowed by the 
receiver. That is, the receiver sequentially receives SD PDUs having sequence 
numbers up to VR(MR) - 1. The receiver should discard the SD PDU having the 
parameter in the N(S) field being equal to or more than VR(MR). It is possible that 
the reception of such an SD PDU causes the transmission of a USTAT PDU. 
Updating manner of the variable VR(MR) can be optional with the device, but the 
variable VR(MR) should not be less than VR(H). 

d) VR(SQ) - RECEIVER CONNECTION SEQUENCE STATE VARIABLE 

This state variable is used to identify retransmitted BGN, ER, and RS PDUs. 
In reaction to the reception of a BGN, ER, or RS PDU, this state variable is compared 
with the value in the N(SQ) field of the received BGN, ER, or RS PDU, and then the 
value in the N(SQ) field is allocated to the variable VR(SQ). In the comparison, if 
they are different, the PDU is processed and the variable VR(SQ) is set to the 
parameter in the N(SQ) field. If they are equal to each other, the PDU is identified as 
a retransmitted one. 
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2.5.2.3.3.1.2.5 LLC PDU PARAMETER FIELDS 

a) N(S) 

The variable VT(S) is mapped to the N(S) field of a new SD, SD-with-POLL, or 
POLL PDU whenever the new SD, SD-with-POLL, or POLL PDU is generated as 
5 represented in Figures 72-74. 

b) Information field 

The information field of an SD, SD-with-POLL, MD, or UD PDU represented 
in Figures 72, 73, or 77 is mapped from the "message unit" parameter of an AA-DATA, 
MAA-UNITDATA, or AA-UNITDATA request. Afterward, the information in this 
10 field is mapped again to a "message unit" parameter of an corresponding AA-DATA, 
MAA-UNITDATA, or AA-UNITDATA indication. 

c) N(PS) 

After the variable VT(PS) has been incremented, the variable VT(PS) is 
mapped to the N(PS) field of an SD-with-POLL or POLL PDU whenever the SD-with- 

15 POLL or POLL PDU is generated as represented in Figures 73 and 74. In addition, 
the receiver of an SD-with-POLL or POLL PDU maps the contents of the N(PS) field of 
the received SD-with-POLL or POLL PDU into the N(PS) field of an STAT PDU as 
represented in Figure 75. To facilitate error recovery procedures, in addition to the 
mapping of the variable VT(PS) into the N(PS) field of the SD-with-POLL or POLL 

20 PDU, the SD-with-POLL or POLL PDU including the N(PS) field is stored in the 
transmitter buffer whenever the PDU is sent. 

d) N(R) 

The variable VR(R) is mapped to the N(R) field of a STAT or USTAT PDU 
whenever the STAT or USTAT PDU is generated as represented in Figures 75 and 76. 
25 e) N(MR) 

The variable VR(MR) is mapped to the N(MR) field of an STAT, USTAT, RS, 
RSAK, ER, ERAK, BGN, or BGAK PDU whenever such a PDU is generated as 
represented in Figures 75, 76, 78, 79, 83, 84, 85, and 86. This variable is the basis for 
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credit granting by the receiver. 

f) SSCOP-UU< 

The SSCOP-UU in a BGN, BGAK, BGREJ, END or RS PDU in Figures 78-81, 
and 83 is mapped to and from the "SSCOP-UU" parameter of the corresponding 
5 SSCOP signal. 

g) SOURCE BIT (S) 

In an END PDU, the source bit (S) field in Figure 81 conveys information as to 
whether the originator of the release initiation was the SSCOP user or the SSCOP 
itself. When the transmission of an END PDU is initiated by the user, this bit is set 
10 to "0." However, when the transmission of an END PDU is initiated by the SSCOP, 
this bit is set to "1." This bit is mapped into the "source" field of an AA-RELEASE 
indication. 

h) N(SQ) 

This field carries the connection sequence value. The variable VT(SQ) is 
15 mapped to the N(SQ) field of a new BGN, RS, or ER PDU whenever the new BGN, RS, 
or ER PDU is transmitted. The parameter in this field is used by the receiver with 
the variable VR(SQ) to identify retransmitted BGN, RS, and ER PDUs. 

i) PDU TYPE FIELD / 

Codings with respect to the PDU type field is represented in the list formed by 
20 Figures 559 and 560. 

2.5.2.3.3.1.2.6 LLC TIMER 

Description with respect to the LLC timer will be omitted. 

25 2.5.2.3.3.1.2.7 LLC PROTOCOL PARAMETERS 

LLC protocol parameters will be described below, 
a) Max-CC 

This is the maximum number of the state variable VT(CC) and corresponds to 
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the maximum limit of transmissions of a BGN, END, ER, or RS PDU. 

b) Max-PD 

This is the maximum number of the state variable VT(PD) before sending a 
POLL PDU and resetting VT(PD) to zero. 

c) Max-STAT 

This is the maximum number of list elements which can be contained in an 
STAT PDU. When the number of list items exceeds the Max-STAT, the STAT message 
shall be segmented. All of the PDUs carrying the segments made from an STAT 
message, except possibly the last one, contain Max-STAT list items. This parameter 
is not used for length check by the receiver of an STAT PDU, but is only used by the 
sender of the STAT message for segmentation purposes. This parameter should be an 
odd integer greater than or equal to 3. The default value of the Max-STAT should be 
studied further. This parameter can be changed dependently on the device. 

The default value causes the STAT PDU to fill six ATM cells using AAL type 5 
common part. In addition, the total length of a STAT PDU should not exceed the 
maximum length of an SD PDU. 

d) Clear-buffers 

This parameter is set upon connection establishment. It holds one of two 
values indicating "Yes" or "No," respectively. If this parameter is set to "Yes," the LLC 
sub-sub-layer can clear its transmission buffer and release transmission queue in 
response to a connection release. If this parameter is set to "No," the LLC sub-sub- 
layer can not clear its transmission buffer and release transmission queue even if 
connection release occurs. Additionally, if this parameter is set to "No," the LLC sub- 
sub-layer cannot clear selectively acknowledged messages from its transmission buffer 
if older ones are still outstanding. 

e) Credit 

This parameter is used to coodinate credit notifications to layer management. 
When the LLC sub-sub-layer is blocked from transmitting a new SD or SD-with-POLL 
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PDU due to insufficient credit, the credit parameter is assigned the value indicating 
"No." When the LLC sub-sub-layer is permitted to transmit a new SD or SD-with- 
POLL PDU, the credit parameter is assigned to the value indicating "Yes." The credit 
parameter is initially assigned "Yes." 



2.5.2.3.3.1.2.8.1 " CREDIT AND PEER-TO-PEER FLOW CONTROL 

Credit is granted by the LLC receiver to allow the peer LLC transmitter to 
transmit new SD or SD-with-POLL PDUs. The process by which a receiver entity 
determined credit is optional, but is related to the buffer availability and the 
bandwidth and delay of the connection. 

The variable VR(MR) is contained in the N(MR) field of each of BGN, BGAK, 
RS, RSAK, ER, ERAK, STAT and USTAT PDUs sent by the receiver, and then 
conveyed to the transmitter. The content of the N(MR) field is read out and stored as 
the variable VT(MS) at the transmitter. The variable VR(MR) sent to the transmitter 
is the sequence number of SD or SD-with-POLL PDU that the receiver will not accept. 

The transmitter does not transmit any SD or SD-with-POLL PDU having the 
sequence number which exceeds the credit allowed. The receiver discards any SD or 
SD-with-POLL PDUs having the sequence number which exceeds the credit allowed. 
In one case, reception of such an SD or SD-with-POLL PDU may cause the 
transmission of a USTAT PDU. 

Previously granted credit can be reduced in order for the receiver to perform 
flow control, but the receiver credit variable VR(MR) cannot be reduced below the 
variable VR(H). In other words, if a receiver has accepted and acknowledged the 
receipt of the SD or SD-with-POLL PDU having the sequence number which is 
VR(H) - 1, the credit value VR(MR) must be greater than or equal to VR(H). 

The lower bound of the operating window according to the LLC protocol is the 
variable VT(A) while the upper bound thereof is VT(MS) - 1. The modulus of the 
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protocol limits the sequence number range of the operating window to 2 s - 1. 
Therefore, the acceptable sequence number (granted credit) at the receiver by the 
modulo arithmetic must be a value between VR(H) and VR(R) - 1. If VR(MR) = VR(R) 
= VR(H), the operating window size is zero. If VR(MR) = VR(R) - 1, the operating 
window size is maximum. 

The LLC receiver allocates a buffer to support each connection. In principle, 
the available receiver buffer should match or exceed the credit granted to the 
transmitter to avoid the discard of successfully transmitted data. However, if 
limitted buffers are availabled for a connection, it is possible to grant credit in excess of 
the available buffer capacity. This method may obtain a higher throughput than can 
be achieved by limiting the credit to the availed buffer, with the possibility that data 
may need to be discarded if errors occur. The receiver cannot discard previously 
received and acknowledged, but not yet delivered, SD or SD-with-POLL PDUs. In 
addition, the receiver must allocate sufficient buffer capacity to receive and deliver the 
SD or SD-with-POLL PDU with the sequence number which is equal to VR(R) at all 
times unless VR(R) = VR(H) = VR(MR). The granting of credit in excess of buffer 
capacity should only be performed if limited buffers are available to support the 
connection and if the LLC receiver can still maintain the quality of service (QOS) 
required for the connection through this method. 



LLC events, such as receptions of PDUs and external and internal signals, are 
normally processed in the order in which they occurred. However, events pertaining 
to the exchange of LLC link status information have priority over other data transfer. 

A device may detect congestion (for example, a long queuing delay) in its lower 
protocol layers. In this case, data transfer should be suspended in order to give 
priority to connection control messages. The means, by which an LLC entity decides 
whether or not congestion occurs, depends on the protocol environment, including 
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protocol timer values. 

If an LLC entity detects a local congestion ("lower layer busy"), it can elect to 
suspend the servicing AA-DATA request signals, AA-UNITDATA request signals, and 
MAA-UNITDATA request signals. It can also suspend the retransmission of 
requested SD or SD-with-POLL PDUs. The data transfer procedures allow this to 
occur without causing protocol errors. 

Therefore, when transmitting PDUs to the peer receiver, all types of PDUs 
except for SD PDU, SD-with-POLL PDU, MD PDU, and UD PDU are given highest 
priority. The SD PDUs, SD-with-POLL PDUs, MD PDUs, and UD PDUs have equal 
priority. Retransmissions of SD PDUs have priority over new transmissions of SD 
PDUs if both PDU types are pending. These priorities are only internal to the LLC. 
The LLC 's local flow control at user's interface is dependent on the device. 



In the following, the format and parameters of an MAC PDU in the MAC sub- 
layer and frame formats and parameters on logical channels will be described with 
reference to Figures 87-94. Figure 87 represents the frame format of an MDU and 
the frame format on the broadcasting channel (BCCH). Figure 88 represents the 
frame format of an MDU and the frame format on the perch channel (PCH). Figure 
89 represents the frame format of an MDU and the format of long and short frame on 
the random access channel (RACH). Figure 90 represents the frame format of an 
MDU and the format oflong frame on the forward access channel (FACH). Figure 91 
represents the frame format of an MDU and the format of short frame on the forward 
access channel (FACH). Figure 92 represents the frame format of an MDU and the 
frame format on the stand alone dedicated control channel (SDCCH). Figure 93 
represents the frame format of an MDU and the frame format on the associated control 
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channel (ACCH). Figure 94 represents the frame format of an MDU and the frame 
format on the user packet channel (UPCH). 

a) PAD 

A PAD field is included in an MAC PDU (MAC sub -layer frame) to extend the 
5 length of the MAC PDU to an integer multiple of the length of a layer 1 frame (extend 
to integer octets). The bit or all bits in the PAD field should be "0." 

b) LENGTH 

A length field is interposed in the MAC PDU for indicating the amount of the 
MAC PDU including the PAD field by the octet. 
10 c) CRC 

A CRC field including an error detection code is attached to each MAC PDU, 
so that the receiver can detect any errors. The result should be used for a 
determination by a higher layer protocol as to whether the frame should be 
retransmitted. Figure 561 represents the relationship between the length of CRC 
15 fields and channels through which corresponding frame is transmitted. 

d) ST 

A segment type (ST) field is included in each layer 1 frame for indicating that 
the corresponding layer 1 frame is the top, middle, or end of the original MAC PDU. 
The segment type is attached when an MAC PDU is disassembled to layer 1 frames, 
20 and referred when an MAC PDU evaluation is assembled from the layer 1 frames. 
Figure 562 represents the bit coding of the ST field and the meaning thereof. 

e) OTHERS 

A BI field in the layer 1 frame in Figure 89 includes a BCCH identity (BI) 
information. Figure 563 represents the bit coding of the BI field and the meaning 
25 thereof. 

An SFN field in the layer 1 frame in Figure 89 includes a system frame 
number (SFN) used for retrieval of the uplink long code phase and for synchronization 
of the super-frames. 



F0220/2551 




223 

An uplink interference field in the layer 1 frame in Figure 89 includes uplink 
interference information indicating the uplink interference level for the corresponding 
sector measured most recently. Figure 564 represents the bit coding of the uplink 
interference field and the meaning thereof. However, when the measurement has not 
been carried out, all of the bits in the uplink interference field should be one. 

A PID field in the layer 1 frame in either of Figures 89 and 90 includes a 
personal identification (PID) of message or mobile station which is identified on the 
RACH or FACH. The identification shall be of the length of 16 bits. Figure 565 
represents the relationship between the usage of the PID field and the range of PID 
value. 

A U/C field in the layer 1 frame on the RACH, FACH or UPCH represented in 
either of Figures 89-91, and 94 includes an identifier for indicating that either of user 
information or control information is included in the layer 1 frame. Figure 566 
represents the bit coding of the U/C field and the meaning thereof. 

ATN field in the layer 1 frame on the RACH, FACH, or UPCH represented in 
either of Figures 89-91, and 94 includes an identifier of the termination or inception. 
Figure 567 represents the bit coding of the TN field and the meanings thereof. 

An MO field in the short layer 1 frame on the FACH represented in Figure 91 
includes a bit for identifying the mode of the FACH. Figure 568 represents the bit 
coding of the MO field and the meanings thereof. 

A CRC field including an error detection code is attached to each layer 1 frame 
as represented in Figures 87 through 94, so that the receiver can detect any errors. 
Figure 569 represents the relationship between the length of CRC fields and channels 
through which corresponding frames are transmitted. 

An S field is attached to the short layer 1 frame on the RACH as represented 
in Figure 89. When an MAC PDU evaluation is assembled from the short layer 1 
frames on the RACH, the bit in the S field contributes to prevent the same layer 1 
frame from duplicating in the MAC PDU. 
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ATA field in the layer 1 frames represented in either of Figures 87 through 94 
includes tail bits as a convolutional code. 

AD field represented in either of Figures 90 through 92 contains dummy bits. 

5 2.5.2.4 LAYER 3 MESSAGES 

Next, messages of layer 3 of the invented system will be described. In the 
following description, ITU-T Recommendations X, I, and Q series will be sometimes 
shortened to X, I, and Q. 

10 2.5.2.4.1 ^ PROTOCOL ARCHITECTURE 

First, the protocol architecture of layer 3 will be described. Figure 95 is a 
conceptual diagram representing an example of the radio interface protocol 
architecture. Among the protocol control entities in Figure 95, CC (call/connection 
control) entity complies with Q.2931 and controls call and connection. MM-P entity 

15 complies with Q.2932 and manages mobility services for users, e.g., user 
authentication. MM-T (terminal mobility management) entity manages mobility 
services for mobile terminals, e.g., terminal location registration and user 
authentication. RRC (radio resource control) entity treats initiations for allocation 
and reservation of radio resources and for activation and deactivation of handover. 

20 TAC (terminal association control) entity establishes and releases signaling 
connections between mobile terminals and the network. 

2.5.2.4.2 MESSAGE FORMATS 

Next, message formats for layer 3 will be described. 
25 2.5.2.4.2.1 FORMATS OF CC ENTITY MESSAGES 

First, CC (call/connection control) entity messages will be described. Figure 
570 is a list representing various messages belonging to the CC entity message. In 
the following, the messages represented in Figure 570 will be described with reference 
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to lists in Figures 571 through 628. In the lists, "M" means mandatory information 
element while "O" means optional information element. "OF" means information 
element that will be used when ATM (asynchronous transfer mode) will be applied to 
radio transmission. 



First, an alerting message will be described. The alerting message is 
transferred from a called user to the network and then transferred from the network to 
a calling user in order to indicate that calling procedure of the called user is started. 
Figure 571 through 573 form a list representing information elements constituting the 
alerting message. As represented in this list, the significance of the alerting message 
is global, the channel on which the alerting message is carried is the ACCH, and the 
direction is both. 

In the list formed by Figure 571, the connection identifier, narrow -band bearer 
capability information element, narrow-band high layer compatibility information 
element, mobile bearer capability information element, and mobile high layer 
information element should be studied further. The broad-band higher layer 
information element is included if the higher layer information selection procedure is 
used. The mobile bearer capability information element will be used when bearer 
capability is selected. 

2.5.2.4.2.1.2 CALL PROCEEDING MESSAGE 

Next, a call proceeding message will be described. The call proceeding 
message is transferred from the network to a calling user or from a called user to the 
network in order to indicate that requested call setup is initiated and no additional call 
setup will be accepted. Figure 574 through 576 form a list representing information 
elements constituting the call proceeding message. As represented in this list, the 
significance of the call proceeding message is global, the channel on which the call 
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proceeding message is carried is the SDCCH or ACCH, and the direction is both. 

2.5.2.4.2. 1.3 CONNECT MESSAGE 

Next, a connect message will be described. The connect message is 
transferred from a called user to the network and from the network to a calling user in 
order to indicate that requested call is accepted by the called user. Figure 577 
through 581 form a list representing information elements constituting the connect 
message. As represented in this list, the significance of the connect message is global, 
the channel on which the connect message is carried is the ACCH, and the direction is 
both. 

As represented in this list, if the called user wants to reply the calling user the 
broadband low layer compatibility information, the broadband low layer compatibility 
information element is included in the connect message from the called user to the 
network. If the connect message from the called user to the network includes the 
broadband low layer compatibility information element, the broadband low layer 
compatibility information element is also included in the connect message from the 
network to the calling user. For the broadband low layer information negotiation, 
this information element is included in the connect message as an option, but some 
network may not transfer this information element to the calling user. 

2.5.2.4.2.1.4 CONNECT ACKNOWLEDGE MESSAGE 

Next, a connect acknowledge message will be described. The connect 
acknowledge message is transferred from the network to a called user in order to 
indicate that the call is established for the called user. In addition, the connect 
acknowledge message is transferred from a calling user to the network in order to 
enable symmetric call control procedure. Figure 582 is a list representing 
information elements constituting the connect acknowledge message. As represented 
in this list, the significance of the connect acknowledge message is local, the channel 
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on which the connect acknowledge message is carried is the ACCH, and the direction is 
both. 

The notification identifier information element is included if the notification 
procedure is applied. A plurality of notification identifier information elements can be 
5 included in this message. The maximum length and the allowable number of the 
elements depend on the network. 

2.5.2.4.2.1.5 PROGRESS MESSAGE 

Next, a progress message will be described. The progress message is 
10 transferred from the network or either of users in order to indicate the event as a call 
progress when the interworking is taken place. Figures 583 through 585 form a list 
representing information elements constituting the progress message. As 
represented in this list, the significance of the progress message is global, the channel 
on which the connect message is carried is the SDCCH or ACCH, and the direction is 
15 both. 

2.5.2.4.2.1.6 SETUP MESSAGE 

Next, a setup message will be described. The setup message is transferred 
from a calling user to the network and from the network to a called user in order to 
20 initiate a call setup. Figures 586 through 594 form a list representing information 
elements constituting the setup message. As represented in this list, the significance 
of the setup, message is global, the channel on which the setup message is carried is the 
SDCCH or ACCH, and the direction is both. 

25 2.5.2.4.2. 1.7 RELEASE MESSAGE 

Next, a release message .will be described. The release message is 
transferred from the network or either of users in order to initiate that the device 
transmitting the release message has disconnected the FPLMTS connection for 
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releasing connection identifier (if connection identifier is used) and call reference. 
The device which has received the release message should release the connection 
identifier, transmit a release complete message, and then release the call reference. 
The above description about the connection identifier will be valid only when the ATM 
5 will be applied on air interface in the future. Figure 595 is a list representing 
information elements constituting the release message. As represented in this list, 
the significance of the release message is global, the channel on which the release 
message is carried is the SDCCH or ACCH, and the direction is both. 

10 2.5.2.4.2.1.8 * RELEASE COMPLETE MESSAGE 

Next, a release complete message will be described. The release complete 
message is transferred from the network or either of users in order to initiate that the 
device transmitting the release complete message has released the connection 
identifier (if connection identifier is used) and call reference. The connection 

15 identifier can be reused by releasing. The device which has received the release 
complete message should release the call reference. The above description about the 
connection identifier will be valid only when the ATM will be applied on air interface in 
the future. Figure 596 is a list representing information elements constituting the 
release complete message. As represented in this list, the significance of the release 

20 complete message is local, the channel on which the release complete message is 
carried is the SDCCH or ACCH, and the direction is both. 

2.5.2.4.2. 1.9 INFORMATION MESSAGE 

Next, an information message will be described. The information message is 
25 transferred from the network or either of users in order to provide additional 
information, more specifically, additional information for call setup (e.g., overlap 
sending) or various information related to call. Figure 597 is a list representing 
information elements constituting the information message. As represented in this 
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list, the significance of the information message is local (however, information with 
global significance can be transferred by this message), the channel on which the 
information message is carried is the SDCCH or ACCH, and the direction is both. 

5 2.5.2.4.2.2 FORMAT OF MM-T ENTITY MESSAGE 

Next, MM-T (terminal mobility management) entity message will be 
described. 

2.5.2.4.2.2.1 MESSAGE BELONGING TO MM-T ENTITY MESSAGE 

Figure 598 is a list representing a message (mobility facility message) 
belonging to the MM-T entity message. 

With respect to various messages including the mobility facility message and 
others, discrimination can be carried out by the message type information element. 
That is, if more significant three bits in the message type information element are 
"Oil," the corresponding message belongs to messages prescribed in Q.2931. In 
addition, if the less significant five bits are "00010," the corresponding message 
belongs to messages prescribed in Q.2932. Otherwise, the corresponding message is 
the mobility facility message. 

20 2.5.2.4.2.2.2 MOBILITY FACILITY MESSAGE 

Figure 599 is a list representing the generic formats of the mobility facility 
message. As represented in this list, the significance of the mobility facility 
message is local, and the direction is both. 

25 2.5.2.4.2.2.3 FACILITY 

The facility information of the mobility facility message in Figure 599 is 
constituted of various information elements in fact. The contents of the facility 
information vary with the usage of the corresponding mobility facility message. Thus, 
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lists of information elements of mobility facility message for various utilization will be 
explained. 

(a) MOBILITY FACILITY MESSAGE FROM MS TO NETWORK FOR 
TERMINAL LOCATION REGISTRATION 

Figures 600 and 601 form a list representing information elements 
constituting a mobility facility message transferred from the mobile station to the 
network for requesting terminal location registration when the terminal location 
should be updated or when the mobile station roams. As represented in the list, the 
protocol discriminator in this message indicates MM-T, the channel on which this 
message is carried is the SDCCH, and the direction is from MCF of the mobile station 
to SACF of the network. 

(b) MOBILITY FACILITY MESSAGE FROM NETWORK TO MS FOR 
TERMINAL LOCATION REGISTRATION 

When the terminal location should be updated or when the mobile station 
roams, another type of mobility facility message (as a response message to the request 
of terminal location registration) is transferred from the network to the mobile station. 
This response message can be classified into three sorts represented in three lists of 
Figures 602 through 604, respectively. As generically represented in those lists, the 
protocol discriminator in each of these messages indicates MM-T, the channel on which 
each message is carried is the SDCCH, and the direction is from SACF of the network 
to MCF of the mobile station. 

(b-1) RESPONSE MESSAGE INDICATING "RETURN RESULT' 1 

When the terminal location has been normally registered, the mobility facility 
message (response message) indicating "return result" represented in Figure 602 is 
sent. 

(b-2) RESPONSE MESSAGE INDICATING "RETURN ERROR" 

When an abnormality, for example, an application error has occurred, the 
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mobility facility message (response message) indicating "return error" represented in 
Figure 603 is sent. 

(b-3) RESPONSE MESSAGE INDICATING "REJECT" 

When an abnormality, for example, a discrepancy of an information element 
has occurred, the mobility facility message (response message) indicating "return 
error" represented in Figure 604 is sent. 

(c) MOBILITY FACILITY MESSAGE FROM NETWORK TO MS FOR TMUI 
ASSIGNMENT 

Figure 605 is a list representing information elements constituting a mobility 
facility message transferred from the network to the mobile station for notifying the 
mobile station of the TMUI allocated to the mobile station. As represented in the list, 
the protocol discriminator in this message indicates MM-T, the channel on which this 
message is carried is the SDCCH, and the direction is from SACF and TACF of the 
network to MCF and TACAF of the mobile station. 

(d) MOBILITY FACILITY MESSAGE FROM MS TO NETWORK FOR TMUI 
ASSIGNMENT 

Another type of mobility facility message (as a response message to the TMUI 
assignment) is transferred from the mobile station to the network. This response 
message can be classified into three sorts represented in three lists of Figures 606 
through 608, respectively. As generically represented in those lists, the protocol 
discriminator in each of these messages indicates MM-T, the channel on which each 
message is carried is the SDCCH, and the direction is from MCF and TACAF of the 
mobile station to SACF and TACF of the network. 

(d-1) RESPONSE MESSAGE INDICATING "RETURN RESULT" 

When the TMUI has been normally assigned, the mobility facility message 
(response message) indicating "return result" represented in Figure 606 is sent. 
(d-2) RESPONSE MESSAGE INDICATING "RETURN ERROR" 

When an abnormality, for example, an application error has occurred, the 
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mobility facility message (response message) indicating "return error" represented in 
Figure 607 is sent. 

(d-3) RESPONSE MESSAGE INDICATING "REJECT" 

When an abnormality, for example, a discrepancy of an information element 
has occurred, the mobility facility message (response message) indicating "return 
error" represented in Figure 608 is sent. 

(e) MOBILITY FACILITY MESSAGE FROM NETWORK TO MS FOR 
AUTHENTICATION CHALLENGE 

Figures 609 and 610 form a list representing information elements 
constituting a mobility facility message transferred from the network to the mobile 
station for authenticating the mobile station by the mobile service switching center. 
As represented in the list, the protocol discriminator in this message indicates MM-T, 
the channel on which this message is carried is the SDCCH or ACCH, and the 
direction is from SACF and TACF of the network to MCF and TACAF of the mobile 
station. 

(f) MOBILITY FACILITY MESSAGE FROM MS TO NETWORK FOR 
AUTHENTICATION CHALLENGE 

Another type of mobility facility message (as a response message to the 
authentication challenge) is transferred from the mobile station to the network. This 
response message can be classified into three sorts represented in three lists of Figures 
611 through 613, respectively. As generically represented in those lists, the protocol 
discriminator in each of these messages indicates MM-T, the channel on which each 
message is carried is the SDCCH or ACCH, and the direction is from MCF and TACAF 
of the mobile station to SACF and TACF of the network. 

(f-1) RESPONSE MESSAGE INDICATING "RETURN RESULT" 

When the authentication has been normally requested, the mobility facility 
message (response message) indicating "return result" represented in Figure 611 is 
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sent. 

(f-2) RESPONSE MESSAGE INDICATING "RETURN ERROR" 

When an abnormality, for example, an application error has occurred, the 
mobility facility message (response message) indicating "return error" represented in 
5 Figure 6 12 is sent. 

(f-3) RESPONSE MESSAGE INDICATING "REJECT" 

When an abnormality, for example, a discrepancy of an information element 
has occurred, the mobility facility message (response message) indicating "return 
error" represented in Figure 613 is sent. 
10 (g) MOBILITY FACILITY MESSAGE FROM NETWORK TO MS FOR 
CIPHERING START NOTIFICATION 

Figure 614 is a list representing information elements constituting a mobility 
facility message transferred from the network to the mobile station for notifying the 
mobile station of ciphering onset. As represented in the list, the protocol 
15 discriminator in this message indicates MM-T, the channel on which this message is 
carried is the SDCCH or ACCH, and the direction is from SACF and TACF of the 
network to MCF and TACAF of the mobile station. 

(h) MOBILITY FACILITY MESSAGE FROM MS TO NETWORK FOR 
CIPHERING START NOTIFICATION 
20 Another type of mobility facility message (as a response message to the 

ciphering start notification) is transferred from the mobile station to the network. 
This response message can be classified into three sorts represented in three lists of 
Figures 615 through 617, respectively. As generically represented in those lists, the 
protocol discriminator in each of these messages indicates MM-T, the channel on which 
25 each message is carried is the SDCCH or ACCH, and the direction is from MCF and 
TACAF of the mobile station to SACF and TACF of the network. 
(h-1) RESPONSE MESSAGE INDICATING "RETURN RESULT" 

When the ciphering onset has been normally notified, the mobility facility 
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message (response message) indicating "return result" represented in Figure 615 is 
sent. 

(h-2) RESPONSE MESSAGE INDICATING "RETURN ERROR" 

When an abnormality, for example, an application error has occurred, the 
mobility facility message (response message) indicating "return error" represented in 
Figure 616 is sent. 

(h-3) RESPONSE MESSAGE INDICATING "REJECT" 

When an abnormality, for example, a discrepancy of an information element 
has occurred, the mobility facility message (response message) indicating "return 
error" represented in Figure 617 is sent. 

(i) MOBILITY FACILITY MESSAGE FROM NETWORK TO MS FOR 
IMUI RETRIEVAL 

Figure 618 is a list representing information elements constituting a mobility 
facility message transferred from the network to the mobile station for inquiring of the 
mobile station as to the IMUI of the mobile station. As represented in the list, the 
protocol discriminator in this message indicates MM-T, the channel on which this 
message is carried is the SDCCH, and the direction is from SACF and TACF of the 
network to MCF and TACAF of the mobile station. 

(j) MOBILITY FACILITY MESSAGE FROM MS TO NETWORK FOR 

IMUI RETRIEVAL 

Another type of mobility facility message (as a response message to the IMUI 
inquiry) is transferred from the mobile station to the mobile service switching center. 
This response message can be classified into three sorts represented in three lists of 
Figures 619 through 621, respectively. As generically represented in those lists, the 
protocol discriminator in each of these messages indicates MM-T, the channel on which 
each message is carried is the SDCCH, and the direction is from MCF and TACAF of 
the mobile station to SACF and TACF of the network. 

(j-1) RESPONSE MESSAGE INDICATING "RETURN RESULT" 
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When the IMUI has been normally inquired, the mobility facility message 
(response message) indicating "return result" represented in Figure 619 is sent. 
(j-2) RESPONSE MESSAGE INDICATING "RETURN ERROR" 

When an abnormality, for example, an application error has occurred, the 
5 mobility facility message (response message) indicating "return error" represented in 
Figure 620 is sent. 

(j-3) RESPONSE MESSAGE INDICATING "REJECT" 

When an abnormality, for example, a discrepancy of an information element 
has occurred, the mobility facility message (response message) indicating "return 
10 error" represented in Figure 621 is sent. 



2.5.2.4.2.3 FORMAT OF RBC ENTITY MESSAGE 

Next, RBC (radio bearer control) entity message will be described. 

2.5.2.4.2.3.1 MESSAGES BELONGING TO RBC ENTITY MESSAGE 

15 Figure 622 is a list representing messages belonging to the RBC entity 

message. 

2.5.2.4.2.3.2 CLASSIFICATION OF RBC ENTITY MESSAGE 

RBC entity message can be classified into two types: one relates to setup and 
20 release of bearer so as to cause an RBC ID to change; and the other relates to maintain 
bearer so as not to cause an RBC ID to change. Figure 623 is a list representing the 
classification of RBC entity message. 

2.5.2.4.2.3.3.1 BASIC MESSAGE FORMAT 

25 Next, the basic format of RBC entity message will be described. Each EBC 

entity message comprises a fundamental part and an optional extensional part. The 
fundamental part is constituted of one or more message-specific-parameter fields and 
one or more optional fundamental information fields. Figure 96 represents the basic 
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format of RBC entity message. 

Message-specific-parameter field in Figure 96 contains at least one unique 
parameter of the message. 

Each fundamental information field includes at least one parameter in 
conformance with the procedure that the message initiates. In other words, 
fundamental information elements in RBC entity messages vary with the necessary 
procedure. Fundamental information field can be used without any design change of 
the invented system. 

On the contrary, extensional information field may be used if the performance 
of the invented system is extended. 

Operation indicator field asterisked in Figure 96 is not included in the RBC 
entity message for the invented system. If a new type of message will be used in the 
system due to performance extension in the future, this field will be used. 

2.5.2.4.2.3.3.2 STRUCTURES OF FRAMES OF RBC ENTITY MESSAGE 

Figure 97 represents structures of frames of an RBC entity message. As 
represented in Figure 97, message-specific-parameter field is mandatory. As to each 
parameter, if the length is variable, the length field indicates that there is no 
instruction. As to each parameter, if there is not a parameter that may be used 
optionally, this fact is indicated by a bit or bits for indicating whether there is a 
parameter or not. 

2.5.2.4.2.3.4 SPECIFIC MESSAGE FORMATS 

Next, specific formats of various messages belonging to RBC entity message 
will be described. 



2.5.2.4.2.3.4.1 RADIO BEARER SETUP MESSAGE 

First, radio bearer setup message will be described. This message is sent 
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from the network to a mobile station in order to setup a radio bearer therebetween. 
Figure 624 is a list representing the format of radio bearer setup message. The 
protocol discriminator of the message indicates RBC, the channel on which the 
message is carried is the SDCCH or ACCH, and the direction is from the network to 
the mobile station. 

2.5.2.4.2.3.4.2 RADIO BEARER RELEASE MESSAGE 

This message is sent from the network to a mobile station or from a mobile 
station to the network in order to release a radio bearer therebetween. Figure 625 is 
a list representing the format of radio bearer release message. The protocol 
discriminator of the message indicates RBC, the channel on which the message is 
carried is the ACCH, and the direction is from the network to the mobile station or 
from the mobile station to the network. 

2.5.2.4.2.3.4.3 RADIO BEARER RELEASE COMPLETE MESSAGE 

This message is sent from the network to a mobile station or from a mobile 
station to the network in order to notify of the release completion of a radio bearer 
therebetween. Figure 626 is a list representing the format of radio bearer release 
complete message. The protocol discriminator of the message indicates RBC, the 
channel on which the message is carried is the ACCH, and the direction is from the 
network to the mobile station or from the mobile station to the network. 

2.5.2.4.2.3.4.4 HANDOVER COMMAND MESSAGE 

This message is sent from the network to a mobile station in order to indicate 
the radio bearer therebetween that is added, deleted, replaced, or substituted at 
handover. Figure 627 is a list representing the format of handover command message. 
The protocol discriminator of the message indicates RBC, the channel on which the 
message is carried is the ACCH, and the direction is from the network to the mobile 
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station. 

2.5.2.4.2.3.4.4 HANDOVER RESPONSE MESSAGE 

This message is sent to respond to a handover command massage, the 
handover command message initiating diversity handover (DHO) branch deletion, 
DHO branch addition, code replacement, and any combination thereof. Figure 628 is 
a list representing the format of handover response message. The protocol 
discriminator of the message indicates RBC, the channel on which the message is 
carried is the ACCH, and the direction is from the mobile station to the network. 

2.5.2.4.2.4 FORMAT OF RRC ENTITY MESSAGE 

Next, RRC (radio resource control) entity message will be described. 

2.5.2.4.2.4. 1 MESSAGE BELONGING TO RRC ENTITY MESSAGE 
Figure 629 is a list representing a message (radio resource facility message) 

belonging to the RRC entity message. Utilization of the ROSE (remote operations 
service element) protocol as the protocol for the RRC entity should be studied further. 
Therefore, this description is based on the ROSE protocol. 

2.5.2.4.2.4.2 RRC ENTITY MESSAGE FORMAT 
2.5.2.4.2.4.2. 1 MOBILITY FACILITY MESSAGE 

Figure 630 is a list representing the format of the RRC facility message sent 
from a mobile station to the network for initiating the RRC procedure. As 
represented in this list, the protocol discriminator of the message indicates RRC, the 
channel on which the message is carried is the SDCCH or ACCH, and the direction is 
from the mobile station to the network. 



2.5.2.4.2.5 



TAC ENTITY MESSAGES 
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Next, TAC (terminal association control) entity messages will be described. 
Figure 631 is a list representing TAC entity messages. Figure 632 is a list 
representing the relationship between TAC entity message and information flow. 
The messages will be explained in detail. 

2.5.2.4.2.5.1 TERMINAL ASSOCIATION SETUP MESSAGE 

This message is sent from a mobile station to the network to indicate the 
start of the terminal association. Figure 633 is a list representing the format of the 
terminal association setup message. The protocol discriminator of the message 
indicates TAC, the channel on which the message is carried is the SDCCH, and the 
direction is from TACAF of the mobile station to TACF of the network. 

2.5.2.4.2.5.2 TERMINAL ASSOCIATION CONNECT MESSAGE 

This message is sent from the network to the mobile station to respond to 
the terminal association setup message for notifying of the requested terminal 
association can be achieved normally. Figure 634 is a list representing the format 
of the terminal association connect message. The protocol discriminator of the 
message indicates TAC, the channel on which the message is carried is the SDCCH, 
and the direction is from TACF of the network to TACAF of the mobile station. 

2.5.2.4.2.5.3 PAGING RESPONSE MESSAGE 

This message is sent from a mobile station to the network to respond to 
paging. Figure 635 is a list representing the format of the paging response 
message. The protocol discriminator of the message indicates TAC, the channel on 
which the message is carried is the SDCCH, and the direction is from TACAF of the 
mobile station to TACF of the network. 



2.5.2.4.2.5.4 



TERMINAL ASSOCIATION RELEASE MESSAGE 
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This message is sent from the network to the mobile station or from the mobile 
station to the network in order to request to release the terminal association 
therebetween. Figure 636 is a list representing the format of the terminal association 
release message. The protocol discriminator of the message indicates TAC, the 
channel on which the message is carried is the SDCCH or ACCH, and the direction is 
from TACF of the network to TACAF of the mobile station and from TACAF of the 
mobile station to TACF of the network. 

2.5.2.4.2.5.5 TERMINAL ASSOCIATION RELEASE COMPLETE 

MESSAGE 

This message is sent from the network to the mobile station or from the mobile 
station to the network in order to respond to the terminal association release message. 
Figure 637 is a list representing the format of the terminal association release 
complete message. The protocol discriminator of the message indicates TAC, the 
channel on which the message is carried is the SDCCH or ACCH, and the direction is 
from TACF of the network to TACAF of the mobile station and from TACAF of the 
mobile station to TACF of the network. 

2.5.2.4.2.5.6 PAGE AUTHORIZED MESSAGE 

This message is sent from the network to the mobile station to notify that the 
terminals have been associated. Figure 638 is a list representing the format of the 
page authorized message. The protocol discriminator of the message indicates TAC, 
the channel on which the message is carried is the SDCCH or ACCH, and the direction 
is from TACF of the network to TACAF of the mobile station. 



2.5.2.4.2.6 OTHER MESSAGES 

In the following, other layer 3 messages which are carried on RACH, FACH, 
BCCH, and PCH will be described. 



f~\. 
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2.5.2.4.2.6. 1 SIGNALING CHANNEL SETUP REQUEST MESSAGE 

This message is sent from a mobile station to a base transceiver system (BTS) 

in order to request to setup an SDCCH therebetween. Figure 639 is a list 
5 representing the format of the signaling channel setup request message. The channel 

on which the message is carried is the RACH, and the direction is from SCMAF of the 

mobile station to SCMF of the BTS. 

Signaling channel setup request messages from mobile stations which 

randomly access the BTS can be identified by PIDs (personal identifications) 
10 corresponding to the mobile stations. As described above, a PID is a random number 

originally determined by the corresponding mobile station and is included in a layer 1 

frame. 



j~| 2.5.2.4.2.6.2 SIGNALING CHANNEL SETUP RESPONSE MESSAGE 

\^ 15 A signaling channel setup response message is sent from a BTS to a mobile 

station in order to setup an SDCCH therebetween. Figure 640 is a list representing 
the format of the signaling channel setup response message. The channel on which 
the message is carried is the FACH, and the direction is from SCMF of the BTS to 
SCMAF of the mobile station. Signaling channel setup response messages to mobile 
20 stations can be identified by PIDs at the mobile stations. 

A signaling channel setup failure message is sent from a BTS to a mobile 
station in order to notify of rejection of the request to setup an SDCCH therebetween. 
Figure 641 is a list representing the format of the signaling channel setup failure 
message. The channel on which the message is carried is the FACH, and the 
25 direction is from SCMF of the BTS to SCMAF of the mobile station. Signaling 
channel setup failure messages to mobile stations can be identified by PIDs at the 
mobile stations. 
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2.5.2.4.2.6.3 BROADCAST INFORMATION MESSAGES 

A first broadcast information message is sent from a BTS to mobile stations in 
order to notify of various information, e.g., control channel structure information, 
information regarding mobile station decision of visited zone, and restriction 
information. Figure 642 is a list representing the format of the first broadcast 
information message. The channel on which the message is carried is the BCCH, and 
the direction is from BCFr of the BTS to each BCAF of mobile station. 

A second broadcast information message is sent from a BTS to mobile stations 
in order to notify of call acceptance information. Figure 643 is a list representing the 
format of the second broadcast information message. The channel on which the 
message is carried is the BCCH, and the direction is from BCFr of the BTS to each 
BCAF of mobile station. 

2.5.2.4.2.6.4 PAGING MESSAGE 

This message is sent from a BTS to mobile stations in order to page to notify of 
a first calling a specific mobile station. Figure 644 is a list representing the format of 
the paging message. The protocol discriminator of the message indicates TAC, the 
channel on which the message is carried is the PCH, and the direction is from BCFr of 
the network to each TACAF of mobile station. 

The paged MS ID in the list indicates the TMUI or IMUI of the paged mobile 
station. At the top of the paged MS ID field, an I/T bit is arranged for indicating that 
either of IMUI and TMUI is used. 

The maximum length of the paging message is 112 bits. Coding manner of 
the paged MS ID asterisked in the list should be studied further. Even when IMUI is 
used for the paged MS ID, it is unnecessary to indicate all bits of IMUI by the paged 
MS ID since lower bits of the UMUI can be recognized from the PCHs calculation 
number. 
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2.5.2.4.3 FORMATS OF INFORMATION ELEMENTS IN MESSAGES 

Next, formats of information elements in the aforementioned messages will be 
described. 

2.5.2.4.3.1 FORMATS OF INFORMATION ELEMENTS IN CC ENTITY 

MESSAGES 

2.5.2.4.3.1.1 COMMON INFORMATION ELEMENTS IN CC ENTITY 

MESSAGES 

First, information elements which are common in CC entity messages will be 
described. Each of CC entity protocol messages may comprise: 

(a) protocol discriminator, 

(b) call reference, 

(c) message type identifier, including a message compatibility instruction 
indicator, and 

(d) variable length information elements if necessary. Information elements 
(a), (b), (c), and (d) are included in each of CC entity protocol messages commonly, as 
represented in Figure 98. However, variable length information elements differ with 
message types. Information elements (a), (b), and (c) are arranged in the order 
represented in Figure 98. 

2.5.2.4.3.1.1.1 PROTOCOL DISCRIMINATOR 

Protocol discriminator will be described next. The protocol discriminator is 
designed for distinguishing the CC entity message from other messages in the 
invented system. In addition, the protocol discriminator is used for distinguishing 
the message in the invented system from other messages prepared from OSI network 
layer protocol data unit encoded in compliance with other ITU-T recommendations, 
TTC standard or other standards. 

The protocol discriminator is arranged at the top of each CC entity message as 
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represented in Figure 98. The protocol discriminator is of eight-bit length as 
represented in Figure 99 and encoded in a manner represented in Figure 645. 

In the invented system, the CC entity messages does not use the same 
signaling virtual channel as that of another layer 3 protocol message. Therefore, the 
5 encoding manners of the protocol discriminator are different. However, if the other 
layer 3 protocol message is capsuled according to ITU-T Recommendation Q.2931, this 
message forms an exception. 

The values in Figure 645 are reserved for distinguishing the protocol 
discriminator from the first octet of a packet, including a general format discriminator, 
10 according to ITU-T Recommendation X.25. 

2.5.2.4.3.1.1.2 CALL REFERENCE 

Call reference is designed for identifying in a local user-network interface a 
message involved in a single call and is not used at the terminal devices 
15 interconnected via B-ISDN (broadband aspects of integrated services digital network). 
The call reference is arranged at the second part of each CC entity message and 
encoded in a manner represented in Figure 100. The entire length of the call 
reference information element is one octet and the length is indicated by bits 1 through 
4. 

20 As represented in Figure 100, the call reference information element includes 

a call reference value and a call reference flag. The call reference value of which all 
bits are "zero" (see Figure 100) is reserved for a global call reference. The call 
reference value of which all bits are "one" (see Figure 101) is reserved for a dummy call 
reference. 

25 The call reference value is allocated to a call by the calling user side of a user- 

network interface. As a general rule, the sole call reference value is allocated to a call 
in a single signaling virtual channel by the calling user side. The call reference value 
is allocated at call onset and maintained to be used throughout the call. After 
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termination of a call, the call reference value is released and may be allocated to 
another call. 

It is possible that both sides of a signaling virtual channel link allocate the 
same call reference value to two calls, respectively, and the same call reference value is 
5 used for two calls in a single signaling virtual channel. In order to avoid such a 
coincidence by a wrong scenario, it is not desirable to reuse the released call reference 
value immediately after the release. 

The call reference flag is restricted to have zero or one. The call reference 
flag identifies which side of the signaling virtual channel allocates the corresponding 

10 call reference. That is, with respect to messages from the calling user to the called 
user, the call reference flag is zero. With respect to messages from the called user to 
the calling user, the call reference flag is one. Therefore, although the same call 
reference value is simultaneously used for messages in two directions, they can be 
distinguished from each other. 

15 The call reference flag is also similarly used for a global call reference, for 

example, at the initial setup procedure. As mentioned above, all bits of a global call 
reference value are zero (see Figure 100). The device, which has received a message 
including a global call reference, should interpret that this message is valid for all 
messages on the signaling virtual channel. 

20 On the other hand, all bits of a dummy call reference value are one (see Figure 

101). In the future, a dummy call reference value will be used for a specific additional 
service. The call reference flag is also similarly used for a global call reference. 
Dummy call reference is not used in procedures of the invented system, so that devices 
of the invented system should discard a message including a dummy call reference. 

25 

2.5.2.4.3. 1.2 MESSAGE TYPE IDENTIFIER 

Next, message type identifier, including message compatibility instruction 
indicator, will be described. 
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The message type identifier is designed for identifying the function of the 
message transmitted. The message type identifier is arranged at the third part of 
each CC entity message and encoded in a manner represented in Figures 102, 646, and 
647. Figure 102 is a diagram representing the format of the message type identifier. 
5 Figures 646 and 647 form a table representing the coding of the message type 
identifier. As mentioned in Figure 646, octet 1 of the message type identifier encoded 
as "00000000" is used for an escape code for a nationally specific message type. In 
addition, as mentioned in Figure 646, octet 1 of the message type identifier encoded as 
"11111111" is reserved for extension for the case that all other values have been used. 

10 On the other hand, the message compatibility instruction indicator is used by 

the message source terminal for explicitly instructing peer entity operation at the 
message destination terminal. The format and the coding manner of the message 
compatibility instruction indicator are represented in Figures 102 and 647. The 
message compatibility instruction indicator is valid only in the defined local interval. 

15 It is optional for the network to decide which value is set to the message compatibility 
instruction indicator of a message transmitted from the network to a user terminal 
insofar as the coding is not prescribed by another manner. 

2.5.2.4.3.1.3 VARIABLE LENGTH INFORMATION ELEMENTS 

20 ACCORDING TO FPLMTS 

Next, variable length information elements according to FPLMTS will be 
described. 

2.5.2.4.3.1.3.1 CODING 
25 Coding of the variable length information elements of CC entity messages will 

be described hereinafter. The coding was studied in order that the device which 
processes messages can detect information elements necessary for the process and can 
ignore other elements. 
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Figures 103 and 104 represent the formats of the variable length information 
elements according to FPLMTS. Figures 648 and 649 form a list representing the 
coding of the variable length information elements according to FPLMTS. Bit coding 
represented in Figures 103, 104, 648, and 649 are reserved for the information 
elements that will be described later. 

As mentioned in Figure 104, information element identifier encoded as 
"11111111" is reserved for extension. If all other information element identifiers have 
been used, further 65536 information elements can be identified by virtue of the 
extension. 

In the CC entity message, variable length information elements can be 
arranged in random order, but the following constitutes exceptions. 

(a) If the broadband repeat indicator information element is not included and the 
same kind of information elements is included, the same kind of information elements 
should be arranged in succession. However, this rule is not applied for broadband 
locking shift information elements and broadband non -locking shift information 
elements. 

(b) If the broadband repeat indicator information element is included and the 
same kind of information elements is included, the following rules will be applied. 

The broadband repeat indicator information element should be arranged 
directly before the first element among the same kind of information elements. 

The first element among the same kind of information elements, which is 
arranged directly after the broadband repeat indicator information element, should be 
interpreted to have the highest priority. The same kinds of information elements 
should be interpreted in such a manner that the element of higher priority is arranged 
ahead. 

The information elements arranged after the broadband non-locking shift 
information element should be processed as an information element in the application 
of the above-described rules. 
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Only one repetition of information element in the message with the broadband 
repetition indicator information element will not be considered an error. That is, the 
broadband repetition indictor should be ignored. 

(c) If the broadband locking shift information element is used, the rule should be 
5 applied to all of the information elements after it. The order of the information 

elements is prescribed by codes indicated in the broadband locking shift information 
element. 

(d) If the broadband non-locking shift information element is used, the broadband 
non-locking shift information element should be arranged directly before the 

10 information element which is subject of that. 

If reserved bits are included in the description of the information used in the invented 
system, all of the reserved bits should be set to zero. Although the reserved bits of a 
received information element are not set to zero, the process for the reserved bits is not 
carried out. 

15 Figures 648 and 649 represent the coding manner of the information element 

identifier. The information element identifier includes an information element 
compatibility instruction indicator at octet 2 thereof as represented in Figure 649. 
The information element compatibility instruction indicator is valid only in the defined 
local interval. It is optional for the network to decide which value is set to the 

20 information element compatibility instruction indicator of a massage included in a 
message transmitted from the network to a user terminal insofar as the coding is not 
prescribed by another manner. 

Octets 3 and 4 of the information element cooperate to indicate the length of 
the information elements minus the total length of the information element identifier 

25 field, information element compatibility instruction indicator field, and information 
element length indicator field itself. For the information element length indicator, 
the number of octets in the information element is encoded into a binary code. The 
information element length indicator is of a fixed length of two octets. The coding 
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manner of the information element length indicator should comply with the coding 
rule of integer described in this section. 

The invented system permits an information element, of which the content is 
empty, to present. For example, it is possible that a setup message includes a called 
number information element of which the octet length is zero. In such cases, the 
receiving device treats in such a manner that the information element is not 
interpreted to be included. Similarly, the exclusion of an expected information 
element is interpreted as an "empty information element" at processing. The "empty 
information element" is the information element which has a (valid) information 
element identifier and is of a length of zero. 

In addition, the following rules are applied to information element coding in 
the invented system. 

(a) The variable length information element constitutes of a single octet or a 
group of octets. A number is allocated to each single octet or octet group for 
facilitating reference. The first number of the octet number indicates single octet or 
octet group. 

(b) Each octet group is an independent unit in an information element. The 
format of octet group can be defined in the following fashion or other fashions. 

(c) Octet groups are prepared by using any extension method. An extension 
method wherein bit eight is used as the extension bit, and an octet (N) will be extended 
to the next octets (Na, Nb,...) is preferable. For example, a methodbased on the below 
rule can be utilized. 

Bit value, zero, indicates that the corresponding bit is not end. Bit value, one, 
indicates that the corresponding bit is end. If an octet (e.g., Nb) exists, preceding 
octets (N) and (Na) also exist. 

Bit eight may be indicated in the descriptions in sections 2.5.2.4.3.1.3.5, and 

so on. 

"0/1 extension" is used when another octet will follow an octet and these octets 
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belong to the same octet group. 

"1 extension" is used when another octet will follow an octet and these octets 
belong to the same octet group. 

"0 extension" is used when another octet will absolutely follow an octet and 
these octets belong to the same octet group. 

When a specification is added, an additional octet can be defined after the 
preceding last octet (In this case, the description of "1 extension" is changed to the 
description of "0/1 extension." Therefore, devices on the invented system should 
accept such an additional octet. However, it is unnecessary that each of the devices 
interprets the additional octet or functions in accordance that. 

(d) In addition to the above -de scribed extension method, the indication of bits 
eight to one of octet (N) can be extended to the next octets (N.l) and (N.2) ? 

(e) The extension methods (c) and (d) can be associated. However, the extension 
method (c) is of high priority. Accordingly, all of octets (Na, Nb...) must precede octets 
(N.l, N.2,...). This rule should be applied to the case that octets (N.l, N.2,...) are 
extended in accordance with the extension method for octets (Na, Nb,...). The same 
rule should be applied to the case that the extension method (d) is repeated. That is, 
octets (N.l, N.2...) should precede octet (N.2). 

(f) Optional octets are marked with asterisks. 

(g) If an information element is assembled using subfield identifiers, these 
subfield identifiers are independent of position. In other words, it is unnecessary that 
they are aligned in a specific order. 

However, it is impossible to repeat to use the extension method (c). That is, 
the extension method for octet 4a cannot be applied to the octet which should become 
octet 4b. In addition, a protocol designer should pay attention for guaranteeing that 
the resulting coding leads a sole interpretation although a plurality of extension 
methods are used. Furthermore, it is prescribed that the coding standard field is 
attached to all information elements. The information element of which the coding 
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standard field is prescribed to "national standard" should be formatted in the same 
manner as the standard format of the invented system. 

The following rules are applied to integer coding of ITU-T Recommendation 
Q.2931. When coding is not designated, the rules are applied. 

(a) When an integer is encoded to the length equal to or more than two octets, the 
octet with a less octet number includes superior bits. Especially,- the octet with the 
least octet number includes the MSB (most significant bit) while the octet with the 
greatest octet number includes the LSB (least significant bit). 

(b) With reference to a field which is within an octet or constitutes a part of an 
octet, the following rules are applied. 

A bit with a greater bit number constitutes a superior bit. 

Especially, the bit with the greatest bit number indicates the MSB (most 
significant bit). 

Especially, the bit with the least bit number indicates the LSB (least 
significant bit). 

Bit coding is carried out from the bit with less bit number (from right). That 
is, preceding parts of zero appear at the side of greater bit number (left) in an octet or 
field. 

(c) When integer values are expressed in fixed length octets, bit coding is carried 
put from the octet with greater octet number. That is, preceding zero parts appears at 
the side of less octet number. 

(d) When integer values are expressed in variable length octets (e.g., when bit 8 is 
used as an extension bit), coding shall be performed so that it becomes the smallest 
number of octets. Octets, of which all the preceding bits are "0," do not exist. 



2.5.2.4.3. 1.2 EXTENSION OF CODE SETS 

Next, extension of code sets will be described. When the format described at 
section 2.5.2.4.3.1.3.1 is used, the information element identifier may take a plurality 
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values. 

Each of information element identifiers may be extended to eight code sets. 
To facilitate to shift from a code set to another code set, a common information element 
identifier is used for these code sets. Based on the contents of the shift information 
element, the code set used for the next-coming information element group or 
information element can be identified. The code set used at an "arbitrary given time is 
used as an "busy code set," and code set 0 will be considered the initial busy code set" 
implicitly. In addition, in the invented system, two code set shift procedures: locking 
shift and non-locking shift procedures are applied. 

Reservation status of code sets will be noted in the following. 

Code sets 1 through 3 are reserved for future use of ITU-T or TTC. 

Code set 4 is reserved for standard use of ISO or IEC. 

Code set 5 is reserved for an information element group utilized domestically. 

Code set 6 is reserved for an information element group specialized for the 
public or private network. 

Code set 7 is reserved for an information element group specialized for users. 

In addition, the coding rules prescribed in section 2.5.2.4.3.1.3.1 will be 
applied to information elements belonging to an arbitrary busy code set. 

Shift from busy code set to another code set (by locking shift) is possible only 
when the value of new code set is higher than that of the former code set. 

When using non-locking shift procedure, the information elements in code sets 
4, 5, 6 and 7 may appear together with one in the busy code set, i.e., code set 0 (see 
section 2.5.2.4.3.1.3.4). 

The user or network device should have the ability to recognize both locking 
and non-locking shift information elements and determine the length of information 
elements that follow them. The device, however, does not need to interpret or 
function according to the content of these information elements. This enables the 
equipment to decide the start point of following information elements. 



F0220/2551 




253 

Code set 7 shall be processed in the first switching equipment in the local 
network in accordance with the unrecognized information element processing 
procedure (see ITU-T Recommendation Q.2931) unless the service definition in the 
future, agreement by both parties, or readiness for special user support via the local 
5 network are provided. 

Code set 6 is reserved for an information element group specialized for local 
networks (public or private networks). It is meaningless when messages are 
transmitted across the boundary between local networks and the boundary between 
national or international networks. Therefore, the information element in code set 6 
10 shall be processed in accordance with the procedure for the information element which 
cannot be recognized by the first switching equipment after the message is 
transmitted across the boundary of the local network (see Section 5.6.8.1 of ITU-T 
Recommendation Q.2931) unless an agreement on two networks is concluded. - 

Code set 5 is reserved for an information element group utilized domestically. 
15 It is meaningless when messages are transmitted across the boundary between 
nations. Therefore, the information element in code set 5 shall be processed in 
accordance with the procedure for the information element which cannot be recognized 
by the first switching equipment after the message is transmitted across the boundary 
between nations (see Section 5.6.8.1 of ITU-T Recommendation Q.2931) unless an 
20 agreement on two networks is concluded. 

Code set 4 is reserved for standard use of ISO or IEC. 

Code sets 1 through 3 are reserved for future use of ITU-T or TTC. 

2.5.2.4.3. 1.3.3 BROADBAND LOCKING SHIFT PROCEDURE 

25 Next, broadband locking shift procedure will be described. In the broadband 

locking shift procedure, an information element is used to indicate a new busy code set. 
The indicated code set is continuously used until another broadband locking shift 
information element appears to indicate the use of another code set. For example, 
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presume that code set 0 is "busy" at the start of analysis of message contents. When 
another broadband locking shift information element appears to indicate the use of 
code set 5, the information element identifier assigned by code set 5 shall be applied to 
the next and following information elements until another shift information element 
appears. 

This procedure is used only for shifting from to a new code set of which the 
value is higher than the former code set, and relates to only messages including the 
broadband locking shift information elements. The initial busy code set at the start of 
analysis of message contents is code set 0. 

Figures 105 and 650 represent the coding format of the broadband locking 
shift information element. 



The broadband non-locking shift procedure is used for temporarily shifting to 
a designated code set with lower or higher priority. In the broadband non-locking 
shift procedure, a broadband non-locking shift information element is used to indicate 
a busy code set which contributes for interpretation of the next single information 
element. After interpreting the next information element, the busy code set used 
before non-locking shift shall be used again for interpreting arbitrary following 
information elements. For example, assume that code set 0 is busy at the start of 
analysis of message contents. When a broadband non-locking shift information 
element appears to indicate the use of code set 6, the information element identifier 
assigned by code set 6 shall be applied only to the next information element. After 
interpreting it, code set 0 shall be applied again to interpret following information 
elements. The broadband non-locking shift information element shall not be 
interpreted as an error even if it indicates the current code set. 

A broadband locking shift information element cannot be arranged directly 
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Next, broadband non-locking shift procedure will be described. 
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after a broadband non-locking shift information element. The reception of the 
combination thereof should be interpreted as that only the broadband locking shift 
information element is received. 

Figures 106 and 651 represent the coding format of the broadband non-locking 
shift information element. 

2.5.2.4.3. 1.3.5 AAL PARAMETERS 

Next, AAL (ATM adaptation layer) parameters will be described. AAL 
parameters are not necessary for the invented system, but it is possible that they are 
necessary when the ATM will be applied on air interface in the future (this should be 
studied further). 

AAL parameter information element is formulated to indicate AAL 
parameters which are requested for an AAL procedure element used for a call and 
which are significant from end to end. This includes all parameters for the AAL sub- 
layer which can be selected by users. The contents of this information element are 
transparent to the network except during interworking. 

The AAL parameter information element should be coded as shown in Figures 
107 through 111 and 652 through 654. The maximum length of this information 
element should be 21 octets. 

In Figure 108, the octets marked with "Note" are included only when octet 7.1 
indicates nX64 kbps or nX8 kbps. In Figures 109 and 110, the indication of octet 
groups 6 through 8 used in connect message is designated in ITU-T Recommendation 
Q.2931. 



Next, ATM traffic descriptor will be described. ATM traffic descriptor is not 
necessary for the invented system, but it is possible that this is necessary when the 
ATM will be applied on air interface in the future (this should be studied further). 



2.5.2.4.3.1.3.6 



ATM TRAFFIC DESCRIPTOR 
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ATM traffic descriptor is formulated to indicate a traffic parameter set contributing to 
regulating the traffic control capability. 

In the invented system, the value of ATM peek cell rate (TTC Standard JT- 
371), which is indicated by the ATM traffic descriptor, designates the user plane 
information rate and total amount of the end-to-end OAM (operation, administration, 
and maintenance) F5 flows generated by users. When the user attempts to use an 
end-to-end OAM F5 flow message, the peak cell rate in the direction reverse to 
unidirectional connection should not be indicated by zero. The peak cell rate is the 
number of cells per second and is represented with an integer in the 3 octets preceded 
by the sub -field. 

The ATM traffic descriptor information element should be coded as shown in 
Figures 112 and 655. The maximum length of this information element should be 20 
octets. 

The peak cell rate of cells of which the CLP (cell loss priority) equals to one is 
not represented in Figure 112. However, if the peak cell rate of cells of which the CLP 
equals to zero is indicated, the difference between the peak cell rate of cells of which 
the CLP equals to zero or one and the peak cell rate of cells of which the CLP equals to 
zero should be used as the peak cell rate of cells of which the CLP equals to one in the 
network resource allocation. However, if only the peak cell rate of cells of which the 
CLP equals to one or zero is indicated, a complete peak cell rate should be used by cells 
with which the CLP is equal to zero. 



Next, broadband bearer capability will be described. Broadband bearer 
capability is not a necessary parameter for the invented system, but it is possible that 
this is necessary when the ATM will be applied on air interface in the future (this 
should be studied further). 

The broadband bearer capability information element is formulated to 
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indicate needed broadband connection-oriented-bearer service (see ITU-T 
Recommendation F.811), which are provided by the network. Therefore, the 
broadband bearer capability information element is included in messages used by the 
network. With reference to the use of the broadband bearer capability information 
5 element concerning confirming the communication possibility, refer to ITU-T 
Recommendation Q. 2931. 

The default for broadband bearer capability does not exist. Therefore, the 
broadband bearer capability information element can be processed by devices of the 
network and user. The broadband bearer capability information element should be 
10 coded as shown in Figures 113 and 656. The maximum length of this information 
element should be 7 octets. 

The octet marked with "Note" in Figure 113 can be included when octet 5 
indicates bearer class X. 

15 2.5.2.4.3.1.3.8 BROADBAND HIGH LAYER INFORMATION (B-HLI) 

Next, broadband high layer information will be described. Broadband high 
layer information element is formulated to provide means for checking communication 
capability of addressed entity (e.g., remote user and interworking unit addressed by a 
calling user, and a higher layer function node of network). The broadband high layer 

20 information element is carried transparently between a calling entity (e.g., calling 
user) and an addressed destination entity in B-ISDN. 

The broadband high layer information element should be coded as shown in 
Figures 114 and 657. The maximum length of this information element should be 13 
octets. 

25 

2.5.2.4.3.1.3.9 BROADBAND LOW LAYER INFORMATION (B-LLI) 

Broadband low layer information will be described next. Broadband low 
layer information element is formulated to provide means for checking communication 
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capability of addressed entity (e.g., remote user and interworking unit addressed by a 
calling user, and a higher layer function node of network). 

The broadband low layer information element is carried transparently 
between a calling entity (e.g., calling user) and an addressed destination entity in B- 
ISDN. The broadband low layer information element is also carried transparently 
from the addressed destination entity to the calling entity for negotiation of broadband 
low layer information (refer to ITU-T Recommendation Q.2931). 

The broadband low layer information element should be coded as shown in 
Figures 115, 116, 658 through 660. The maximum length of this information element 
should be 17 octets. 

The octet marked with "Note 1" in Figure 115 is included only when octet 6 
indicates the procedure of acknowledge type HDLC. The octet marked with "Note 2" 
exists only if octet 6 indicates the user-specific layer 2 protocol. The octet marked 
with "Note 3" exists only if octet 7 indicates the layer 3 protocol in accordance with the 
ITU-T Recommendation X.25, ISO/IEC 8208, ITU-T Recommendation X.223, or 
ISO/IEC 8878 in Figures 658 through 660. The octet marked with "Note 4" exists 
only if octet 7 indicates the user-specific layer 3 protocol. The octets marked with 
"Note 5" exist only if octet 7 indicates ISO/IEC TR9577. 

2.5.2.4.3.1.3.11 CALLED PARTY NUMBER 

Called party number will be described next. Called party number 
information element is formulated to indicate the called party. The called party 
number information element should be coded as shown in Figures 117 and 661. The 
maximum length of this information element should depend on the network. 

In Figure 117, the number digits appear in the same order as input, beginning 
from inferior four bits in octet 6. The digits are coded with BCD. When the use of 
NASP address is indicated in the address/numbering plan identification, the address 
shall be coded with the expression of ITU-T Recommendation X.213 or ISO/IEC8348. 
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Filler shall be "1111." 

2.5.2.4.3.1.3.12 CALLED PARTY SUB-ADDRESS 

Called party sub-address will be described. Called party sub-address 
element is formulated to indicate the sub-address of the called party. With reference 
to the definition of sub-address, refer to ITU-T Recommendation 1.330. The called 
party sub -address information element should be coded as shown in Figures 118 and 
662. The maximum length of this information element should be 25 octets. 

2.5.2.4.3.1.3.13 CALLING PARTY NUMBER 

Calling party number will be described next. Calling party number 
information element is formulated to indicate the calling party. The calling party 
number information element should be coded as shown in Figures 119, 663, and 664. 
The maximum length of this information element should depend on the network. 

As marked with "Note 1" in Figure 119, the number digits appear in the same 
order as input, beginning from inferior four bits in octet 6. The digits are coded with 
BCD. When the use of NASP address is indicated in the address/numbering plan 
identification, the address shall be coded with the expression of ITU-T- 
Recommendation X.213 or ISO/IEC8348 as marked with "Note 2." Filler shall be 
"1111." 

2.5.2.4.3.1.3.14 CALLING PARTY SUB-ADDRESS 

Calling party sub-address will be described. Calling party sub-address 
element is formulated to indicate the sub-address of the calling party. With reference 
to the definition of sub-address, refer to ITU-T Recommendation 1.330. The calling 
party sub-address information element should be coded as shown in Figures 120 and 
665. The maximum length of this information element should be 25 octets. 
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2.5.2.4.3.1.3.15 CAUSE 

The definition and use of cause information element are defined in ITU-T 
Recommendation Q.2610. 

5 2.5.2.4.3.1.3.16 CONNECTION IDENTIFIER 

Connection identifier will be described next. Connection identifier is not 

necessary for the invented system, but it is possible that this is necessary when the 

ATM will be applied on air interface in the future (this should be studied further). 

Connection identifier information element is formulated to indicate a local ATM 
10 connection resource on the interface. This information element is included as an 

option in the setup message and is included as an option in the first response message 

to the setup message. 

The connection identifier information element should be coded as shown in 

Figures 121 and 666. The maximum length of this information element should be 9 
15 octets. 

If the change addition indicator field designates an "arbitrary VCI," the VCI 
field in Figure 121 must be ignored. If the restart class is "001" (see ITU-T 
Recommendation Q.293 1), the VCI field should be ignored. If VP-associated signaling 
is designated in octet 5, the VPCI field must be ignored. 

20 

2.5.2.4.3.1.3.17 END-TO-END TRANSIT DELAY 

End-to-end transit delay will be described. End-to-end transit delay 
information element is formulated to indicate the substantial maximum end-to-end 
transit delay permitted in each call and to indicate the cumulative transit delay 
25 expected in the virtual connection. This transit delay is the uni-directional end-to- 
end transit delay of user data transferred during data transfer phase on the user plane 
between the calling user and the called user. It includes the total process time in the 
end user system and the cumulative transfer delay. The total process time in the end 
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user system includes, e.g., process time, AAL handling delay, ATM cell assembly delay, 
and delay of all other processes. The network transfer delay includes, e.g., 
propagation delay, ATM layer transfer delay, and all other process delay in the 
network. 

The cumulative transit delay value indicated in the SETUP message by the 
calling user (if any) indicates the transit delay from the calling user to the network 
boundary. The cumulative transit delay value, indicated by the network, in the setup 
message sent to the called user is the sum of the value indicated by the UNI connected 
with the calling party and transfer delay cumulated in the network. It does not 
include the transfer delay in the route between the network boundary to the called 
user. Each of the cumulative transit delay in connection messages on both UNIs is 
the total end-to-end transit delay expected for the user data transfer on the virtual 
channel connection offered to the corresponding call. 

The maximum end-to-end transit delay can be used by the calling user to 
indicate the end-to-end delay request for the call. This field is contained in the setup 
message by the network and used for indicating that the calling user instructs the 
end-to-end delay request to the call. With reference to the applicable procedure, refer 
to ITU-T Recommendation Q.2931. The maximum end-to-end transit delay is not 
included in the connect message. 

The end-to-end transit delay information element should be coded as shown in 
Figures 122 and 667. The maximum length of this information element should be 10 
octets. 



Quality of service (QOS) parameter will be described next. In the invented 
system, QOS parameter information element is formulated in addition to the end-to- 
end transit delay information element. The QOS parameter information element is 
designed to indicate a QOS class. 



2.5.2.4.3.1.3.18 
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QOS parameter information element is not supported in B-ISUP Release 1. 
Consequently, a network cannot transmit the QOS parameter information element, 
and therefore, generates a default value of the QOS parameter information element, 
which does not indicate QOS class, at the termination interface. 
5 The QOS parameter information element should be coded as shown in Figures 

123 and 668. The maximum length of this information element should be 6 octets. 

2.5.2.4.3.1.3.19 BROADBAND REPEAT INDICATOR 

Broadband repeat indicator will be described next. Broadband repeat 
10 indicator information element is formulated to indicate how to interpret a plurality of 
the same kind of information elements which are included in the same message. This 
is arranged before the first one of the same kind of information elements. However, 
even if the broadband repeat indicator is arranged before the information element 
solely included in a single message, this should not be interpreted as an error. 
15 The broadband repeat indicator information element should be coded as 

shown in Figures 124 and 669. The maximum length of this information element 
should be 5 octets. 

2.5.2.4.3. 1.3.20 RESTART INDICATOR 

20 Restart indicator will be described next. Restart indicator should be defined 

in detail in the future (this should be studied further). Restart indicator information 
element is formulated to identify a facility class which is initially designated. 

2.5.2.4.3.1.3.21 BROADBAND SENDING COMPLETE 

25 Broadband sending complete will be described next. Broadband sending 

complete information element is formulated to indicate the completion of the called 
party number as an option (see ITU-T Recommendation Q.2931). This information 
element is mandatory for the batch mode procedure. If this information element does 
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not exist, however, the normal error process for "mandatory information element 
missing" does not need to be performed. 

The broadband sending complete information element should be coded as 
shown in Figure 125. The maximum length of this information element should be 5 
octets. 

2.5.2.4.3.1.3.22 TRANSIT NETWORK SELECTION 

Transit network selection will be described next. Transit network selection 
information element is formulated to indicate a transit network being requested. A 
plurality of transit network selection information elements may be included in the 
same message for indicating the order of transit networks through which the call is 
transferred (see ITU-T Recommendation Q.2931). 

The transit network selection information element should be coded as shown 
in Figures 126 and 670. The maximum length of this information element should 
depend on the network. 

2.5.2.4.3.1.3.23 NOTIFICATION INDICATOR 

Notification indicator information element will be described next. 
Notification indicator information element is formulated to notify of information 
related to the call. The notification indicator information element should be coded as 
shown in Figure 127. The maximum length of this information element is flexible as 
long as it does not contradict with the maximum length of the message. 

2.5.2.4.3.1.3.24 OAM TRAFFIC DESCRIPTOR 

OAM traffic descriptor will be described next. OAM traffic descriptor is not 
necessary for the invented system, but it is possible that this is necessary when the 
ATM will be applied on air interface in the future (this should be studied further). 
OAM traffic descriptor information element is formulated to provide information in 
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relation to end-to-end OAM F5 information flow used to manage the performance on 
the user connection included in the call, and failure caused by the user. 

The OAM traffic descriptor information element should be coded as shown in 
Figures 128 and 671. The maximum length of this information element should be 6 
octets. 

2.5.2.4.3.1.4 INFORMATION ELEMENTS FOR SUPPORTING 64 KBPS 

CIRCUIT SWITCHED MODE ISDN SERVICE 
Next, information elements for supporting 64 kbps circuit switched mode 
ISDN service will be described. 

2.5.2.4.3.1.4.1 CODING RULES 

First, coding rules of the information elements will be described. The information 
elements which will be described in section 2.5.2.4.3.1.4 are coded pursuant to the 
usual information element format represented in Figure 103. The coding of these 
information elements should comply with the coding rules in ITU-T Recommendation 
Q.931 and ITU-T Recommendation Q.2931. 

2.5.2.4.3.1.4.2 « NARROW-BAND BEARER CAPABILITY 

Narrow -band bearer capability will be described next. Narrow-band bearer 
capability is not necessary for the invented system, but it is possible that this is 
necessary when the ATM will be applied on air interface in the future (this should be 
studied further). Narrow-band bearer capability information element is formulated 
to indicate a request for narrow-band ISDN circuit switched mode bearer service 
provided by the network. This information element includes only the information 
which may be used by the network (see ITU-T Recommendation Q.931). The use 
method of narrow-band bearer capability information element related to the 
confirmation of communication feasibility is described in ITU-T Recommendation 
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Q.931. The narrow-band bearer capability information element is transparently 
transferred in the broadband ISDN. The narrow-band bearer capability information 
element should be coded as shown in Figure 129. 

2.5.2.4.3.1.4.3 NARROW-BAND HIGH LAYER COMPATIBILITY 

Narrow-band high layer compatibility information element is formulated to 
offer the procedure for the destination user to confirm the communication feasibility 
(see ITU-T Recommendation Q.931). The narrow-band high layer compatibility 
information element should be coded as shown in Figure 130. The maximum length 
of this information element should be 7 octets. 

However, the narrow-band high layer compatibility information element is 
transparently carried between the calling entity (e.g., calling user) and called entity 
(peer entity or higher later function node in the network) addressed by the calling 
entity in the broadband ISDN. When it was explicitly requested by the user upon 
subscription contract, the network with the tele-service feature may analyze this 
information to offer certain tele-service. 

• 2.5.2.4.3.1.4.4 NARROW-BAND LOW LAYER COMPATIBILITY 

Narrow-band low layer compatibility will be described next. Narrow-band 
low layer compatibility information element is formulated to provide means for 
confirming the feasibility with the entity whose address was designated (e.g., remote 
user addressed by the calling user, interworking unit or higher layer function node of 
network). 

The narrow-band low layer compatibility information element is carried 
transparently between the calling entity (e.g., calling user) and called entity addressed 
by the calling entity in the broadband ISDN. In addition, the narrow-band low layer 
compatibility information element is carried transparently from the called entity to 
the calling entity for the narrow-band low layer compatibility negotiation (ITU-T 
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Recommendation Q.931). 

The narrow-band low layer compatibility information element should be coded 
as shown in Figure 131. The maximum length of this information element should be 
20 octets. 

2.5.2.4.3.1.4.5 PROGRESS INDICATOR 

Progress indicator will be described next. Progress indicator information 
element is formulated to indicate an event occurring during call generation. At most, 
two progress indicator elements are included in the same message. 

The progress indicator information element should be coded as shown in 
Figure 132. The maximum length of this information element should be 6 octets. 

2.5.2.4.3.2 FORMATS OF INFORMATION ELEMENTS IN MM-T 

ENTITY MESSAGES 
Next, formats of information elements in MM-T entity messages will be 
described. With reference to the list of MM-T specific information elements in Figure 
672, the information elements will be described below. 

(1) TMUI 

TMUI is a temporary number for identifying a mobile station and is updated 
at terminal location registration or updating. At call origination and termination, the 
TMUI is not updated unless the network recognizes the TMUI disaccord. 

Figure 133 represents the format of TMUI information element. As 
represented in Figure 133, the TMUI information element consists of an M-SCP 
identification number (10 bits) and a unique identification number (20 bits plus 2 bits) 
and is encoded with the normal binary coding. In the unique identification number, 
two bits are allocated to double assignment evasion bits. 

M-SCP identification number is used to identify the M-SCP which has 
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assigned the TMUI and takes a value between zero and 999. Unique identification 
number is used to identify the mobile station in the node which has assigned the TMUI 
and takes a value between zero and 999999. The double assignment evasion bits are 
used for evading double assignment of the same TMUI and takes a value between zero 
and three. 

(2) TMUI ASSIGNMENT SOURCE ID 

TMUI Assignment Source ID will be described next. As represented in 
Figure 134, TMUI assignment source ID consists of an MCC (mobile country code), 
MNC (mobile network code), and LAI and is encoded with the BCD in the system. 

(3) IMUI 

IMUI will be described next with reference to Figure 135. IMUI is a number 
for recognition of a mobile station used in the network. IMUI includes an MCC and 
MNC, is of a variable length equal to or less than 15 places, and is encoded with BCD. 

(4) EXECUTION AUTHENTICATION TYPE 

Next, with reference to Figure 136, execution authentication type will be 
described. Execution authentication type is information for indicating the 
authentication procedure to be executed when a plurality of authentication procedures 
can be applicable for a mobile station. 

(5) AUTHENTICATION RANDOM PATTERN 

Next, with reference to Figure 137, authentication random pattern will be 
described. Authentication random pattern indicates a random pattern for 
authentication at a mobile station. 



(6) 



AUTHENTICATION CIPHERING PATTERN 
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Next, with reference to Figure 138, authentication ciphering pattern will be 
described. Authentication ciphering pattern indicates a ciphering pattern obtained 
by the mobile station on the basis of the authentication random pattern. 

(7) EXECUTION CIPHERING TYPE 

Next, with reference to Figure 139, execution ciphering type will be described. 
Execution ciphering type is information to indicate the ciphering procedure to be 
executed when a plurality of ciphering procedures can be applicable for a mobile 
station. 

(8) TC INFORMATION 

Next, with reference to Figure 140, TC information will be described. TC 
information is information used for identifying the type of mobile station. 

2.5.2.4.3.3 INFORMATION ELEMENTS OF RBC ENTITY MESSAGES 

Information elements of RBC entity messages will be described next. 

2.5.2.4.3.3.1 MESSAGE TYPE IDENTIFIER 

As represented in Figure 141, message type identifier is formulated to identify 
the function of the corresponding transmitted message. This does not include an 
operation instruction indicator. The various types of messages in Figure 141 will be 
described later. 

2.5.2.4.3.3.2 INFORMATION ELEMENT IDENTIFIER 

Next, information element identifier will be described with reference to Figure 
142. Information element identifier identifies optional information included in the 
corresponding message. When octet 1 of the identifier is "11111111," octet 2 and 
following octets can be valid. Bit 8 of octet 2 and following octets is used as an 
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extension flag by which the next octet can be valid. No identifiers in relation to 
specific parameters are decided. The various types of messages in Figure 142 will be 
described later. 

2.5.2.4.3.3.3 RADIO BEARER SETUP MESSAGE SPECIFIC 

PARAMETER 

Figure 143 represents the format of radio bearer setup message specific 
parameter. In Figure 143, RBC ID (RBC identifier) is a number for identifying the 
RBC connection. The RBC connection uniquely corresponds to a connection which 
can be identified by a CR (call reference) and CONN ID (connection identifier) in the 
CC protocol. The CR is a call identifier for the CC protocol (see section 2.5.2.4.3.1). 
The CONN ID is a connection identifier for the CC protocol (see section 2.5.2.4.3.1). 

2.5.2.4.3.3.4 RADIO BEARER RELEASE MESSAGE SPECIFIC 

PARAMETER . 

Figure 144 represents the format of radio bearer release message specific 
parameter. As represented in Figure 144, radio bearer release message specific 
parameter consists of an RBC ID and cause indicator. 

20 2.5.2.4.3.3.5 RADIO BEARER RELEASE COMPLETE MESSAGE 

SPECIFIC PARAMETER 
Figure 145 represents the format of radio bearer release complete message 
specific parameter. As represented in Figure 145, radio bearer release complete 
message specific parameter consists of only an RBC ID. 

25 

2.5.2.4.3.3.6 HANDOVER COMMAND MESSAGE SPECIFIC 

PARAMETER 

Figure 146 represents the format of handover command message specific 




F0220/2551 




270 

parameter. As represented in Figure 146, handover command message specific 
parameter consists of only an invoke ID. The invoke ID is an identifying number for 
associating a response signal with a handover command when the handover command 
has been initiated. 

5 

2.5.2.4.3.3.7 HANDOVER RESPONSE MESSAGE SPECIFIC 

PARAMETER 

Figure 147 represents the format of handover response message specific 
parameter. As represented in Figure 147, handover response message specific 
10 parameter consists of only an invoke ID. 

2.5.2.4.3.3.8 RADIO BEARER SETUP INFORMATION ELEMENT 
Figures 148 through 151 represent the format of radio bearer setup 

information. In Figure 148, "information element identifier" indicates the radio 
15 bearer setup fundamental information element and has a length of 8 bits. "Length" 

indicates the length of the information element. "Frequency band" field indicates the 

frequency band which should be indicated at the first call. 256 frequency bands can 

be indicated, i.e., frequency band fl is indicated by "00000000" in the "frequency band" 

and frequency band f256 is indicated by "11111111." "BTS number" field indicates the 
20 BTS identifying number in the network which is one or more. "Sector number" field 

indicates the sector identifying number in the same BTS, i.e., sector 1 is indicated by 

"00000001" while sector 12 is indicated by "00001100." 

"Uplink short code type" field indicates the information transfer rate for an 

uplink code (see Figure 150). "Number of uplink codes" field indicates the number of 
25 uplink short codes between one and N when a plurality of uplink short codes are 

availed for a single connection. "Uplink short code number" field indicates the 

identifying number of uplink short code between zero and 2047. 

"Downlink short code type" field indicates the information transfer rate for a 
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downlink code (see Figure 150). "Number of downlink codes'* field indicates the 
number of downlink short codes between one and M when a plurality of downlink short 
codes are availed for a single connection. "Downlink short code number" field 
indicates the identifying number of downlink short code between zero and 2047. 

"Frame offset group" field indicates which time slot in a single radio frame 
should be the front end of the logical frame when the mobile station communicates. 
This is formulated to uniformize traffic in a single frame time unit within the wired 
path. "Frame offset group" takes a value of 0-15 (see Figure 151). 

"Slot offset group" field indicates an offset value of downlink transmission 
timing for a short code. The downlink transmission timing may be offset by, at most, 
three subslots in order to reduce redundancy of pilot symbols. The indication by the 
"slot offset group" field at the first call should be contained until the release of all calls 
of the mobile station (see Figure 151). 



Figures 152 through 154 represent the format of DHO (diversity handover) 
branch addition information element. In Figure 152, "information element identifier" 
field is a length of eight bits and represents DHO branch addition information element. 
"Number of RBC IDs " field indicates the number (from 1 to H) of the simultaneous 
connections. Other fields have been already described. 

2.5.2.4.3.3.10 DHO BRANCH DELETION INFORMATION ELEMENT 

Figure 155 represents the format of DHO (diversity handover) branch deletion 
information element. In Figure 155, "information element identifier" field is a length 
of eight bits and represents DHO branch deletion information element. Other fields 
have been already described. 



2.5.2.4.3.3.9 



, DHO BRANCH ADDITION INFORMATION ELEMENT 
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2.5.2.4.3.3.11 ACCH REPLACEMENT INFORMATION ELEMENT 
Figure 156 represents the format of ACCH replacement information element. 

In Figure 156, "information element identifier" field is a length of eight bits and 
represents ACCH replacement information element. Other fields have been already 
described. 

2.5.2.4.3.3. 12 BRANCH REPLACEMENT INFORMATION ELEMENT 
Figures 157 through 159 represent the format of branch replacement 

information element. In Figure 157, "information element identifier" field is a length 
of eight bits and represents branch replacement information element. Other fields 
have been already described. 

2.5.2.4.3.3.13 USER RATE REPLACEMENT INFORMATION ELEMENT 
Figures 160 through 163 represent the format of user rate replacement 

information element. In Figure 160, "information element identifier" field is a length 
of eight bits and represents user rate replacement information element. Other fields 
have been already described. 

2.5.2.4.3.3.14 CODE REPLACEMENT INFORMATION ELEMENT 
Figures 164 and 165 represent the format of code replacement information 

element. In Figure 164, "information element identifier" field is a length of eight bits 
and represents code replacement information element. "Number of former short 
codes" field indicates the number (from 1 to N) of former short codes used before the 
short code replacement or rearrangement procedure. "Former short code number" 
field indicates the identifying number (from 0 to 2047) of former short code used before 
the short code replacement or rearrangement procedure. "Number of new short 
codes" field indicates the number (from 1 to M) of new short codes after the short code 
replacement or rearrangement procedure. "New short code number" field indicates 
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the identifying number (from 0 to 2047) of new short code after the short code 
replacement or rearrangement procedure. Other fields have been already described. 

2.5.2.4.3.4 INFORMATION ELEMENTS OF RRC ENTITY MESSAGES 

Next, information elements of RRC entity messages will be described. 

2.5.2.4.3.4. 1 MESSAGE TYPE IDENTIFIER 

Message type identifier will be described with reference to Figure 166. 
Message type identifier is formulated for identifying the function of the message 
transmitted. 

2.5.2.4.3.4.2 FACILITY INFORMATION ELEMENT 

The format of facility information element is represented in Figure 167. In 
Figure 167, "profile" field indicates the type of PDU (protocol data unit) which is 
contained in octet 4 and later octets, i.e., ROSE protocol data unit, CMIP protocol data 
unit, or ACSE protocol data unit. "PDU" field includes one or more PDUs which are 
ASEs (application service elements) identified by the "profile" field. In the invented 
system, ROSE protocol is used. 

2.5.2.4.3.4.3 ROSE PDU 

Figures 168 and 169 represent the format of ROSE PDU. In Figure 168, 
"component type tag" is mandatory for each component and indicates the type of 
component (invoke, result return (termination), error return, rejection, result return 
(proceeding), and so on). "Component length" indicates the length of component 
excluding the lengths of component type tag field and component length field. 
"Invoke identifier tag" is used as a reference number for identifying the operation 
invoke, thereby associating a request with a response. "Invoke identifier length" 
indicates the length of the "invoke identifier" field. "Invoke identifier" indicates the 
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invoke identifier. "Operation value tag" is included in the invoke component, and so 
on for indicating the type of operation (local operation or global operation) which 
should be invoked. "Operation value" indicates the type of information for defining 
the operation, i.e., information on the candidate zones for call attempt or acceptance, 
on the in-use zone, on the added zone for DHO, on the deleted zone for DHO, on the 
zone for HHO, on the outer loop, or on the quality deterioration notification. 

2.5.2.4.3.4.4 SPECIFIC PARAMETERS FOR OPERATIONS 

Next, specific parameters for defining operations will be described. 

(a) CANDIDATE ZONE INFORMATION FOR CALL ATTEMPT OR 
ACCEPTANCE 

First, specific parameters of the candidate zone information for call attempt or 
acceptance will be described. This information is sent from the mobile station to the 
network to notify the network of the radio wave reception conditions, measured by the 
mobile station at the call attempt or acceptance, with respect to the visited sector and 
circumferential sectors. Figure 673 represents parameters of the candidate zone 
information. Perch channel reception SIR and perch channel transmission power in 
Figure 673 are used for controlling downlink transmission power. 

(b) IN-USE ZONE INFORMATION 

Next, specific parameters of the in-use zone information will be described. 
This information is sent from the mobile station to the network to initiate the 
downlink radio transmission power control based on the radio wave reception 
condition, measured by the mobile station, with respect to the in-use sector. Figure 
674 represents parameters of the in-use zone information. 

(c) ADDED ZONE INFORMATION FOR DHO 

Next, specific parameters of the added zone information for DHO will be 
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described. This information is invoked by the mobile station to cause the network to 
add one or more diversity links during communication, and includes parameters on the 
candidate sector(s) to be added and radio reception conditions about the candidate 
sector and the in-use sector. Figure 675 represents parameters of the added zone 
information for DHO. 

Only the candidate sector about which the radio reception condition is in 
excess of a threshold for DHO branch addition is added. However, if the condition 
about the candidate sector is worse than conditions of all in-use sectors when the 
number of the in-use sectors is the maximum, the DHO trigger indicating the added 
zone information for DHO is not sent. 

(d) DELETED ZONE INFORMATION FOR DHO 

Next, specific parameters of the deleted zone information for DHO will be 
described. This information is invoked by the mobile station to cause the network to 
execute the diversity link deletion based on the radio reception condition about in-use 
sectors measured by the network. Figure 676 represents parameters of the deleted 
zone information for DHO. 

The radio reception conditions about the in-use sectors are compared with a 
threshold for DHO branch deletion. Then, only the sector about which the radio 
reception condition is lower than the threshold for DHO branch deletion is deleted. 
On the contrary, this information is not sent for the sector which will be deleted 
instead of the sector added by the DHO branch addition although the radio reception 
condition is not lower than the threshold. 

(e) HHO (HARD HANDOVER) ZONE INFORMATION 

Next, specific parameters of the HHO zone information will be described. 
This information is invoked by the mobile station to cause the network to execute the 
branch replacement handover based on the radio reception conditions about the in-use 
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sector and circumferential sectors measured by the network. Figure 677 represents 
parameters of the HHO zone information. 

(f) OUTER LOOP INFORMATION 

Next, specific parameters of the outer loop information will be described. 
This information is invoked by the mobile station to cause the network to execute outer 
loop transmission power control for the downlink radio channel. Figure 678 
represents parameters of the outer loop information. 

(g) QUALITY DETERIORATION NOTIFICATION INFORMATION 

Next, specific parameters of the quality deterioration notification information 
will be described. This information is invoked by the mobile station to cause the 
network to execute the branch replacement wherein channel is replaced to another 
channel with a different frequency when the mobile station detects quality 
deterioration with respect to the downlink radio channel. Figure 679 represents 
parameters of the quality deterioration notification information. 



Next, the definitions of the specific parameters for defining operations will be 
described. 



2.5.2.4.3.4.5 



DEFINITIONS OF SPECIFIC PARAMETERS FOR 



OPERATIONS 



2.5.2.4.3.4.5.1 



NUMBER OF VISITED CANDIDATE SECTORS, NUMBER 



OF IN-USE VISITED SECTORS, NUMBER OF 



CANDIDATE SECTORS TO BE ADDED AT DHO, NUMBER 



OF SECTORS TO BE DELETED AT DHO, AND 



CANDIDATE SECTORS FOR HHO 



Figure 170 represents the common format of parameters of number of visited 
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candidate sectors, number of in-use visited sectors, number of candidate sectors to be 
added at DHO, number of sectors to be deleted at DHO, and candidate sectors for HHO. 
In Figure 170, "number of sectors" field contains a binary code representing a value 
between 1 and N. 

x 

2.5.2.4.3.4.5.2 BTS NUMBER 

Figure 171 represents the format of a parameter of BTS number. "BTS 
identifier" in Figure 171 is a number more than one for identifying the corresponding 
BTS in the network. 

2.5.2:4.3.4.5.3 SECTOR NUMBER 

Figure 172 represents the format of a parameter of sector number. "Sector 
identifier" in Figure 172 is a value of 1-12 for identifying the corresponding sector in 
the BTS. 

2.5.2.4.3.4.5.4 PERCH CHANNEL RECEPTION SIR 

Figure ,173 represents the format of a parameter of perch channel reception 
SIR. "Perch channel reception SIR" in Figure 173 indicates the perch channel 
reception SIR of the visited sector, circumferential sector, or in-use sector measured at 
the mobile station. 

2.5.2.4.3.4.5.5 PERCH CHANNEL TRANSMISSION POWER 

Figure 174 represents the format of a parameter of perch channel 
transmission power. 

2.5.2.4.3.4.5.6 LONG CODE PHASE DIFFERENCE 

Figure 175 represents the format of a parameter of long code phase difference. 
"Long code phase difference" in Figure 175 indicates the difference between the long 
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code phase of the visited or in-use sector and that of a circumferential sector (to which 
the connection may be handed over). This is used when the execution of DHO and the 
zone selection at call attempt or acceptance. If the difference is in excess of 128 chips, 
the field of long code phase difference should be extended by setting the extension bit 
to 1. 

2.5.2.4.3.4.5.7 NUMBER OF RBC IDs 

Figure 176 represents the format of a parameter of the number of RBC IDs. 
The "number of RBC IDs" field in Figure 176 contains a binary code representing a 
value between 1 and N. 

2.5.2.4.3.4.5.8 RBC ID 

Figure 177 represents the format of a parameter of RBC ID. "RBC ID" in 
Figure 177 is a number for identifying the RBC connection which uniquely corresponds 
to a connection which can be identified by a CR (call reference) and CONN ID 
(connection identifier) in the CC protocol. It takes a value between 1 and H. 

2.5.2.4.3.4.5.9 NECESSARY SIR 

Figure 178 represents the format of a parameter of necessary SIR. 

2.5.2.4.3.4.5.10 FER MEASUREMENT 

Figure 179 represents the format of a parameter of FER measurement. 

2.5.2.4.3.5 FORMATS OF INFORMATION ELEMENTS OF TAC 

(TERMINAL ASSOCIATION CONTROL) ENTITY 
MESSAGES 

Next, formats of information elements of TAC entity messages will be 
described. 
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2.5.2.4.3.5.1 GENERAL DESCRIPTION OF TAC (TERMINAL ASSOCIATION 
CONTROL) ENTITY MESSAGES 

Each TAC entity message may comprise: 
5 (a) protocol discriminator, 

(b) message type identifier, 

(c) message specific parameter (if necessary), 

(d) fundamental information element (if necessary), and 

(e) extensional information element (if necessary). 

10 Although elements (a) and (b) are included in all of the TAC entity messages 

commonly, elements (c) through (d) may be included in specific messages on demand. 

Figure 180 represents an example of TAC entity message. The first two 
information elements (protocol discriminator and message type identifier) should 
appear in the order designated in Figure 180. 

15 

2.5.2.4.3.5.2 PROTOCOL DISCRIMINATOR 

First, the protocol discriminator will be described. The protocol 
discriminator is formulated to distinguish the TAC entity message from other 
messages used in the invented system and from other OSI network layer protocol unit 
20 messages encoded in accordance with another ITU-T recommendation, TTC 
recommendation, and another recommendation. The protocol discriminator is located 
at the first part of each TAC entity message and encoded in the manner shown in 
Figure 181. 

25 2.5.2.4.3.5.3 MESSAGE TYPE IDENTIFIER (INCLUDING MESSAGE 

COMPATIBILITY INSTRUCTION INDICATOR) 
Next, the message type identifier will be described. 

The message type identifier is formulated to identify the function of the TAC 
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entity message. The message type identifier is located at the second part of each TAC 
entity message and encoded in the manner shown in Figures 182 and 680. 

The message compatibility instruction indicator is valid only in the defined 
local interval. It is optional for the network to decide which value is set to the 
5 message compatibility instruction indicator of a message transmitted from the 
network to a user terminal insofar as the coding is not prescribed by another manner. 
In the invented system, it is encoded as "000." 

2.5.2.4.3.5.4 MESSAGE SPECIFIC PARAMETER 

The message specific parameter is used for indicating specific information 
necessary for the message. This will be described in detail in the following. 

2.5.2.4.3.5.4.1 TAC ENTITY MESSAGE SPECIFIC PARAMETERS 

Figure 681 is a list representing the TAC entity message specific parameters. 

(1) TERMINAL ASSOCIATION SETUP MESSAGE SPECIFIC PARAMETER 

The terminal association setup message specific parameter is encoded in the 
manner represented in Figures 183 and 682. 

20 (2) PAGING RESPONSE MESSAGE SPECIFIC PARAMETER 

The paging response message specific parameter is encoded in the manner 
represented in Figures 184 and 683. 




25 



(3) TERMINAL ASSOCIATION RELEASE MESSAGE SPECIFIC PARAMETER 
The terminal association release message specific parameter is encoded in the 
manner represented in Figures 185 and 684. 
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2.5.2.4.3.5.4.2 SUBFIELDS OF TAC ENTITY MESSAGE SPECIFIC 

PARAMETERS 

Next, sub fields of TAC entity message specific parameters will be described. 

(1) CODING RULES 

First, coding rules of sub fields of TAC entity message specific parameters will 
be described. The coding of the subfields should comply with the coding rule which 
will be described below. These rules are formulated in order that devices which treats 
the TAC entity messages can identify information elements that are necessary for 
procedures. Figure 685 is a list representing information elements which may be 
contained in subfields of TAC entity message specific parameters. For coding integer 
values in subfields of TAC entity message specific parameters, the following rules 
should be applied. 

(a) When an integer is encoded to the length equal to or more than two octets, the 
octet with a less octet number includes superior bits. Especially, the octet with the 
least octet number includes the MSB (most significant bit) while the octet with the 
greatest octet number includes the LSB (least significant bit). 

(b) With reference to a field which is within an octet or constitutes a part of an 
octet, the following rules are applied. 

A bit with a greater bit number constitutes a superior bit. 
Especially, the bit with the greatest bit number indicates the MSB (most 
significant bit). 

Especially, the bit with the least bit number indicates the LSB (least 
significant bit). 

Bit coding is carried out from the bit with less bit number (from right). That 
is, preceding parts of zero appear at the side of greater bit number (left) in an octet or 
field. 
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(c) When integer values are expressed in fixed length octets, bit coding is carried 
out from the octet with greater octet number. That is, preceding zero parts appears at 
the side of less octet number. 

(d) When integer values are expressed in variable length octets, coding shall be 
performed so that it becomes the smallest number of octets. Octets, of which all the 
preceding bits are "O," do not exist. 

(2) CAUSE INFORMATION ELEMENT 

The cause information element is used for indicating the cause of release of 
terminal association and is encoded in the manner represented in Figures 186 and 
686. 

(3) MOBILE STATION TYPE INFORMATION ELEMENT 

The mobile station type information element is used for identifying the type of 
mobile station and is encoded in the manner represented in Figures 187 and 687. 

(4) PAGED MS ID INFORMATION ELEMENT 

The paged MS ID information element is used for identifying the paged mobile 
station and is encoded in the manner represented in Figures 188 and 688. 

(5) PAGING ID INFORMATION ELEMENT 

The paging ID information element is allocated to a call for managing the call 
when a mobile station is paged. It is encoded in the manner represented in Figure 
189. 

(6) TMUI INFORMATION ELEMENT 

The TMUI information element is used for identifying respective mobile 
stations and is updated when the location is registered and when the location 
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registration is updated. It is encoded in the manner represented in Figures 190 and 
689. 



2.5.2.4.3.5.5 EXTENSIONAL INFORMATION ELEMENT 

5 Any extensional information elements for TAC entity messages are not used in 

the invented system and may be used for extension in the future. The extensional 
information elements for TAC entity messages may be encoded in the manner 
represented in Figure 191. 

10 2.5.2.4.3.6 OTHERS 

In the following, other layer 3 messages which are carried on RACH, FACH, 
BCCH, and PCH will be described. 

2.5.2.4.3.6.1 MESSAGE TYPE 

15 Figure 192 represents the format of the message type information element. 

2.5.2.4.3.6.2 LENGTH 

Figure 193 represents the format of the length information element which 
indicates the length of the message. 



20 



25 



2.5.2.4.3.6.3 PERCH CHANNEL RECEPTION SIR 

Figure 194 represents the format of the perch channel reception SIR 
information element which indicates the signal-to-interference ratio about a signal 
received from the perch channel. 

2.5.2.4.3.6.4 SHORT CODE NUMBER 

Figure 195 represents the format of the short code number information 
element which indicates the short code number for the uplink or downlink SDCCH and 
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which takes a value between zero and 2047. 

2.5.2.4.3.6.5 FRAME OFFSET GROUP 

Figure 196 represents the format of the frame offset group information 
element which indicates the frame offset group for the SDCCH. 

2.5.2.4.3.6.6 SLOT OFFSET GROUP 

Figure 197 represents the format of the slot offset group information element 
which indicates the slot offset group for the SDCCH. 

2.5.2.4.3.6.7 NETWORK NUMBER 

Figure 198 represents the format of the network number information element. 

2.5.2.4.3.6.8 NETWORK VERSION 

Figure 199 represents the format of the network version information element 
which indicates the network version. 

j 

2.5.2.4.3.6.9 MOBILE STATION COMMON PARAMETER VERSION 
Figure 200 represents the format of the mobile station common parameter 

version information element which indicates the version of a parameter common to 
mobile stations. 

2.5.2.4.3.6.10 BTS NUMBER 

Figure 201 represents the format of the BTS number information element 
which indicates the identification number of a BTS. 

2.5.2.4.3:6.11 SECTOR NUMBER 

Figure 202 represents the format of the sector number information element 
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which indicates a sector number in a BTS. It may take a value between one and six 
or between one and 12. 

2.5.2.4.3.6. 12 NUMBER OF OVERLAPPED REGISTRATION AREAS 

5 Figure 203 represents the format of the information element indicating the 

number (N) of registration areas overlapped in one radio zone. 

2.5.2.4.3.6. 13 AREA NUMBER 
Figure 204 represents the format of the area number information element 

which indicates the registration area where the mobile station exists. It takes a value 
between zero and 255. 

2.5.2.4.3.6. 14 AREA REGISTRATION TIMER 
Figure 205 represents the format of the area registration timer information 

element. 

2.5.2.4.3.6. 15 CALIBRATED POWER LEVEL NECESSARY FOR 

RECEPTION AT BASE STATION 

Figure 206 represents the format of the information element indicating the 
calibrated power level necessary for reception at the base station. 

2.5.2.4.3.6. 16 UPLINK LONG CODE NUMBER 
This should be studied further. The uplink long code number information 

element will indicate the uplink long code number on the RA.CH and SDCCH in the 
25 future. 



10 
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2.5.2.4.3.6.17 NUMBER OF PERCH CHANNEL LCs FOR 

DETERMINATION OF VISITED ZONE 

Figure 207 represents the format of the information element indicating the 
number (M) of perch channel LCs for determination of visited zone. 

2.5.2.4.3.6. 18 PERCH CHANNEL LC NUMBER 

The perch channel LC number will be used in the future. This should be 
studied further. 

2.5.2.4.3.6.19 NUMBER OF FREQUENCY BANDS USED BY BASE 

STATION 

Figure 208 represents the format of the information element indicating the 
number (K) of frequency bands used by the base station. 

2.5.2.4.3.6.20 FREQUENCY BAND 

Figure 209 represents the format of the frequency band information element 
indicating the frequency band used on the TCH. 

2.5.2.4.3.6.21 RESTRICTED INFORMATION 

This information element will be used in the future for indicating information 
on access restriction because of construction, of malfunction or of other reasons. This 
should be studied further. 

2.5.2.4.3.6.22 CALL ACCEPTANCE INFORMATION 

The call acceptance information element will be used in the future for 
indicating to the mobile station whether a new call can be accepted or not. This 
should be studied further. 
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2.5.2.4.3.6.23 CONTROL CHANNEL FORMAT INFORMATION 

The control channel format information element will be used in the future for 
indicating the number of PCHs, the number of RACHs for the long code, the number of 
RACHs for the short code, the number of FACHs for the long code, the number of 
5 FACHs for the short code, the code numbers used, and the slot positions. The control 
channel format information element may include information for packets. This 
should be studied further. 

2.5.2.4.3.6.24 BCCH RECEPTION DURATION 

y 10 Figure 210 represents the format of the BCCH reception duration information 

j element indicating the duration through which the mobile station is capable of 

p receiving broadcasting information from the BCCH after the reception of a message 

j: including this information element. 

CSV 

U 15 2.5.2.4.3.6.25 NUMBER OF PAGED MOBILE STATIONS 

Figure 211 represents the format of the information element indicating the 
number of paged mobile stations paged by one paging message. The number takes a 
value of 1-2. 

20 2.5.2.4.3.6.26 PAGED MS ID 

Figure 212 represents the format of the paged MS ID information element, of 
which the length is 112 bits, indicating the IMUI or TMUI of the paged mobile station. 
Detailed coding manner will be decided in the future. 

25 2.5.2.4.3.6.27 PAGING ID 

Figure 213 represents the format of the paging ID information element. 



2.5.2.4.3.6.28 



EXTENS I ON AL INFORMATION ELEMENT 



id 
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Other extensional information elements will be decided in the future. 

2.5.3 SPECIFICATIONS OF BTS-MCC INTERFACE 

Next, the specifications of the BTS-MCC interface will be described. 

2.5.3.1 OUTLINE 

First, an outline will be described. In section 2.5.3, protocols of layers 1 
through 3 at the BTS-MCC interface will be described. 



10 2.5.3.2 LAYER 1 

Layer 1 is formulated for BS transmission line interfaces and for BSC 
transmission line interfaces. Therefore, description thereof is omitted. 



5 



2.5.3.3 ATM LAYER 

fU 15 Similarly, ATM layer is formulated for BS transmission line interfaces and for 

Uj BSC transmission line interfaces. Therefore, description thereof is omitted. 

—~ 

2.5.3.4 AAL COMMON PART SUBLAYER 

Similarly, AAL common part sublayer is formulated for BS transmission line 
20 interfaces and for BSC transmission line interfaces. Therefore, description thereof is 
omitted. 

2.5.3.5 AAL SERVICE SPECIFIC SUBLAYER 

Similarly, AAL service specific sublayer is formulated for BS transmission line 
25 interfaces and for BSC transmission line interfaces. Therefore, description thereof is 
omitted. 
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2.5.3.6 



LAYER 3 



In the following, layer 3 will be described. 



2.5.3.6.1 



PROTOCOL ARCHITECTURE 



Layer 3 protocol architecture in the BTS-MCC interface will be described. In 
addition, layer 3 protocol control entities will be described. Procedures executed in 
the BTS-MCC interface are as follows: 

(1) BTS-MCC Link Control Procedures 

Link establishment and release procedures for the SDCCH between SCMF 
and TACF and between SCMF and SACK 

Access link establishment between TACF and BCFr. 

(2) Paging Procedure 

Paging instruction from TACF to BTS. 

(3) Radio Wave Status Management Procedure 

Status measurement of radio channels between RFTR and RRC (However, 
this procedure is not used in the invented system). 

(4) Other Procedures Such as Transferring Information to BTS 

In accordance with the aforementioned procedures, the following layer 3 
protocol control entities are used in the invented system. 

(a) BC (bearer control) 

This entity prepares and transfers messages for controlling the link between 
TACF and BCFr. That is, it carries out one of procedures (1) mentioned above. 

(b) BSM (base station management) 

This entity prepares and transfers a message for instructing to page the BTS 
and any other messages for managing the BTS. That is, it carries out procedures (2) 
and (4). 

(c) RCM (radio condition management) 
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This entity prepares and transfers a message for measuring conditions of 
radio resources, but is not used in the invented system. 

Next, the protocol architecture in the interface will be described. Messages 
from the data link layer are identified by the protocol discriminators, link references, 
5 and transaction IDs, on the link for control signals at the BTS-MCC interface, and 
then distributed to destination protocol control entities. Figure 214 is a conceptual 
diagram representing the protocol architecture on the BTS-MCC interface. 

2.5.3.6.2 MESSAGE FORMATS 

10 Next, formats of messages transferred on the BTS-MCC interface will be 

described. 

2.5.3.6.2.1 BC ENTITY MESSAGES 

First, BC entity messages will be described. 

15 

2.5.3.6.2.1.1 TYPES OF BC ENTITY MESSAGES 

Figure 690 is a list representing types of BC entity messages. As listed, 
bearer setup messages, bearer release messages, and other messages belong to BC 
entity messages. 

20 

2.5.3.6.2.1.2 CLASSIFICATION OF TYPES OF BC ENTITY MESSAGES 
BC entity messages in the invented system can be classified into two groups: 
one group includes messages for establishing and releasing links according to 

AAL type 2 for the TCHs or SDCCHs. An request for establishing and releasing links 
25 according to AAL type 2 for the ACCH and a request for controlling radio channels 
within the BTS may be included as information elements in one of these messages. 

the other includes messages not relevant to state transition of BC protocol 
entity. If the above request for the ACCH or for controlling radio channels within the 
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BTS do not accompany with control of links according to AAL type 2 for TCHs or 
SDCCHs, a message not relevant to state transition of BC protocol entity is prepared 
including the request as an information element and is transported. Figure 691 

represents the BC entity messages according to the classification. 

5 

2.5.3.6.2.1.3 MESSAGE FORMAT 

Each message comprises common parts and one or more optional fundamental 
information elements as represented in Figure 215. The fundamental information 
element includes a parameter according to the necessary procedure, so that the 
10 parameter depends on the procedure. 

2.5.3.6.2.1.3.1 LINK SETUP REQUESTED MESSAGE 

The link setup requested message will be described. This message is sent 
from the BTS to the MSCNW (more specifically, BSC function) to select a short cell 

15 connection corresponding to resources, such as a short code and a radio facility after 
the selection of such resources by the BTS while the SDCCH is started to be 
established. Figure 692 represents the structural information elements of the link 
setup requested message. As represented in the list, the protocol discriminator in 
this message indicates BC, the connection identification is control signal between the 

20 BTS and the MSCNW (BSC function), and the direction is from SCMF of the BTS to 
SACF and TACF of the MSCNW (BSC function). 

2.5.3.6.2.1.3.2 LINK SETUP MESSAGE 

The link setup message will be described. This message is sent from the 
25 MSCNW (BSC function) to the BTS when the MSCNW (BSC function) has completed 
to select a short cell connection only at the establishment of a TCH. This message is 
also sent from the MSCNW (BSC function) to the BTS to activate a radio bearer. 
Figure 693 represents the structural information elements of the link setup message. 
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As represented in the list, the protocol discriminator in this message indicates BC, the 
connection identification is control signal between the BTS and the MSCNW (BSC 
function), and the direction is from SACF and TACF of the MSCNW (BSC function) to 
SCMF of the BTS, and from TACF of the MSCNW (BSC function) to BCFr of the BTS. 



The link setup proceeding message will be described. This message is sent 
from the BTS to the MSCNW (BSC function) to notify of the selection results of radio 
resources and activation results of radio facilities at the first call, the second call, and 
the hard handover. Figure 694 represents the structural information elements of the 
link setup proceeding message. As represented in the list, the protocol discriminator 
in this message indicates BC, the connection identification is control signal between 
the BTS and the MSCNW (BSC function), and the direction is from BCFr of the BTS to 
TACF of the MSCNW (BSC function). 



The link setup response message will be described. This message is sent 
from the BTS to the MSCNW (BSC function) to notify of the completion of the 
establishment of radio bearer for the first radio branch at the first call, the second call, 
and the hard handover. This message is also sent from the BTS to the MSCNW 
(BSC function) to notify of the selection results of radio resources and activation 
results of radio facilities at the second call and the hard handover. This message is 
also sent from the BTS to the MSCNW (BSC function) to notify of the synchronization 
instruction results at the base station when the SDCCH is established. Figure 695 
represents the structural information elements of the link setup response message. 
As represented in the list, the protocol discriminator in this message indicates BC, the 
connection identification is control signal between the BTS and the MSCNW (BSC 
function), and the direction is from BCFr of the BTS to TACF of the MSCNW (BSC 



2.5.3.6.2.1.3.3 



LINK SETUP PROCEEDING MESSAGE 



2.5.3.6.2.1.3.4 



LINK SETUP RESPONSE MESSAGE 
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function), and from SCMF of the BTS to SACF and TACF of the MSCNW (BSC 
function). 

2.5.3.6.2.1.3.5 LINK FACILITY MESSAGE 

The link facility message will be described. This message is sent from the 
MSCNW (BSC function) to the BTS in order to initiate to add and delete radio 
resources and radio facilities when intra-cell HOSHO is carried out, and in order to 
initiate the ACCH replacement. Figure 696 represents the structural information 
elements of the link facility message. As represented in the list, the protocol 
discriminator in this message indicates BC, the connection identification is control 
signal between the BTS and the MSCNW (BSC function), and the direction is from 
TACF of the MSCNW (BSC function) to BCFr of the BTS. 

2.5.3.6.2.1.3.6 LINK FACILITY MESSAGE 

The link facility message will be described. This link facility message is 
different from that described at section 2.5.3.6.2.1.3.5. This message is sent from the 
BTS to the MSCNW (BSC function) in order to notify of the result of the initiation to 
add and delete radio resources and radio facilities when intra-cell HOSHO is carried 
out, and in order to notify of the result of the initiation of the ACCH replacement and 
the squelch. Figure 697 represents the structural information elements of the link 
facility message. As represented in the list, the protocol discriminator in this 
message indicates BC, the connection identification is control signal between the BTS 
and the MSCNW (BSC function), and the direction is from BCFr of the BTS to TACF of 
the MSCNW (BSC function). 

2.5.3.6.2.1.3.7 LINK RELEASE MESSAGE 

The link release message will be described. This message is sent from the 
MSCNW (BSC function) to the BTS to release a radio bearer. Figure 698 represents 



F0220/2551 




294 

the structural information elements of the link release message. As represented in 
the list, the protocol discriminator in this message indicates BC, the connection 
identification is control signal between the BTS and the MSCNW (BSC function), and 
the direction is from TACF of the MSCNW (BSC function) to BCFr of the BTS, and 
5 from SACF and TACF of the MSCNW (BSC function) to SCMF of the BTS. 

2.5.3.6.2.1.3.8 LINK RELEASE COMPLETE MESSAGE 

The link release complete message will be described. This message is sent 

from the BTS or the MSCNW (BSC function) in order to indicate that the message 
10 transmitting device has released the link reference and the connection identifier. The 

device which receives the message should release the link reference. Figure 699 

represents the structural information elements of the link release complete message. 

As represented in the list, the protocol discriminator in this message indicates BC, the 

connection identification is control signal between the BTS and the MSCNW (BSC 
15 function), and the direction is from BCFr of the BTS to the TACF of the MSCNW (BSC 

function), and from SACF and TACF of the MSCNW (BSC function) to SCMF of the 

BTS. 

If this message is the first link reference release message, the cause indication 
information element is mandatory. This information element is also included in the 

20 message if this message is sent as a result of the error process condition. 

To supplement the above description, Figure 700 represents a list of the 
combinations of the fundamental information elements in the link setup message in 
various uses. Figure 701 represents a list of the combinations of the fundamental 
information elements in the link setup proceeding message in various uses. Figure 

25 702 represents a list of the combinations of the fundamental information elements in 
the link setup response message in various uses. Figure 703 and 704 form a list of the 
combinations of the fundamental information elements in the link facility message in 
various uses. Figure 705 and 706 form a list of the combinations of the fundamental 
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information elements in the other link facility message in various uses. 



2.5.3.6.2.2 



FORMAT OF BSM ENTITY MESSAGE 



Next, formats of BSM entity messages will be described. Each BSM entity 
message may comprise a protocol discriminator, message type identifier, and one or 
more fundamental information elements as represented in Figure 216. 

Figure 217 represents the pattern of fundamental information elements. As 
will be apparently understood by Figure 217, in the fundamental information element, 
an information element identifier and a length identifier are provided before each 
parameter. 

Figure 707 is a list representing a message belonging to the BSM entity 
message. As will be clearly understood by Figure 707, only a paging message belongs 
to the BSM entity message. 



The paging message will be described. This message is sent from the 
MSCNW (BSC function) to the BTS in order to page a mobile station for notifying that 
it is called. Figure 708 represents the structural information elements of the paging 
message. As represented in the list, the protocol discriminator in this message 
indicates BSM, the connection identification is control signal between the BTS and the 
network (BSC function), and the direction is from TACF of the network (BSC function) 
toBCFr of the BTS. 

The area number information element of the paging message is mandatory 
when the BTS manages a plurality of area numbers for paging in a plurality of paging 
areas for multiple area registration. The IMUI or TMUI is used as the paged MS ID. 



2.5.3.6.2.2.1 



PAGING MESSAGE 



2.5.3.6.2.3 



DETAILED DESCRIPTION OF INFORMATION 
ELEMENTS 
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Next, the information elements will be described in detail. 

2.5.3:6.2.3.1 INFORMATION ELEMENTS OF BC ENTITY MESSAGES 

Information elements of BC entity messages will be described. 

2.5.3.6.2.3.1.1 PATTERN OF EACH FUNDAMENTAL INFORMATION 

ELEMENT 

Figure 218 represents the pattern of each fundamental information element. 

2.5.3.6.2.3.1.1.1 LINK ID INFORMATION ELEMENT 

Figure 709 represents the format of the link ID information element (one of 
fundamental information elements). This information element may be included in 
the link setup or link release messages from SACF and TACF of the network (BSC 
function) to SCMF and BCFr of the BTS. 

2.5.3.6.2.3.1.1.2 TCH SETUP REQUEST INFORMATION ELEMENT 

WITHOUT FREQUENCY INDICATION (CALL INITIATED) 

Figure 710 represents the format of the TCH setup request information 
element without frequency indication. This information element may be included in 
the link setup message from TACF of the network (BSC function) to BCFr of the BTS. 

2.5.3.6.2.3.1.1.3 TCH SETUP REQUEST INFORMATION ELEMENT 

WITHOUT FREQUENCY INDICATION (ACTIVE) 

Figure 711 represents the format of the TCH setup request information 
element without frequency indication. This information element may be included in 
the link setup message from TACF of the network (BSC function) to BCFr of the BTS. 
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2.5.3.6.2.3.1.1.4 TCH SETUP REQUEST INFORMATION ELEMENT WITH 

FREQUENCY INDICATION 

Figure 712 represents the format of the TCH setup request information 
element with frequency indication. This information element may be included in the 
link setup message from TACF of the network (BSC function) to BCFr of the BTS. 

2.5.3.6.2.3.1.1.5 DHO BRANCH ADDITION REQUEST INFORMATION 

ELEMENT 

Figure 713 represents the format of the DHO branch addition request 
information element. This information element may be included in the link setup 
message from TACF of the network (BSC function) to BCFr of the BTS. 

2.5.3.6.2.3.1.1.6 INTRA-BS DHO BRANCH ADDITION REQUEST 

INFORMATION ELEMENT 

Figure 714 represents the format of the intra-BS DHO branch addition 
request information element. This information element may be included in the link 
setup or link facility messages from TACF of the network (BSC function) to BCFr of 
the BTS. 

2.5.3.6.2.3.1.1.7 ACCH SETUP REQUEST INFORMATION ELEMENT 
Figure 715 represents the format of the ACCH setup request information 

element. This information element may be included in the link setup or link facility 
messages from TACF of the network (BSC function) to BCFr of the BTS. 

2.5.3.6.2.3.1.1.8 TCH SETUP ACCEPTANCE INFORMATION ELEMENT 

WITHOUT FREQUENCY INDICATION (CALL INITIATED) 

Figure 716 represents the format of the TCH setup acceptance information 
element without frequency indication. This information element may be included in 
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the link setup proceeding message from BCFr of the BTS to TACF of the network (BSC 
function). 

2.5.3.6.2.3.1.1.9 TCH SETUP ACCEPTANCE INFORMATION ELEMENT 

WITHOUT FREQUENCY INDICATION (ACTIVE) 
Figure 717 represents the format of the TCH setup acceptance information 
element without frequency indication. This information element may be included in 
the link setup proceeding message from BCFr of the BTS to TACF of the network (BSC 
function). 



2.5.3.6.2.3.1.1.10 TCH SETUP ACCEPTANCE INFORMATION ELEMENT 

WITH FREQUENCY INDICATION 

Figure 718 represents the format of the TCH setup acceptance information 
element with frequency indication. This information element may be included in the 
15 link setup proceeding message from BCFr of the BTS to TACF of the network (BSC 
function). 

2.5.3.6.2.3.1.1.11 TCH SETUP RESPONSE INFORMATION ELEMENT 

WITHOUT FREQUENCY INDICATION (CALL INITIATED) 

20 Figure 719 represents the format of the TCH setup response information 

element without frequency indication. This information element may be included in 
the link setup response message from BCFr of the BTS to TACF of the network (BSC 
function). 

25 2.5.3.6.2.3.1.1.12 TCH SETUP RESPONSE INFORMATION ELEMENT 

WITHOUT FREQUENCY INDICATION (ACTIVE) 
Figure 720 represents the format of the TCH setup response information 
element without frequency indication. This information element may be included in 
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the link setup response message from BCFr of the BTS to TACF of the network (BSC 
function). 

2.5.3.6.2.3.1.1.13 TCH SETUP RESPONSE INFORMATION ELEMENT 

WITH FREQUENCY INDICATION 

Figure 721 represents the format of the TCH setup response information 
element with frequency indication. This information element may be included in the 
link setup response message from BCFr of the BTS to TACF of the network (BSC 
function). 

2.5.3.6.2.3.1.1.14 DHO BRANCH ADDITION RESPONSE 

INFORMATION ELEMENT 

Figure 722 represents the format of the DHO branch addition response 
information element. This information element may be included in the link setup 
response message from BCFr of the BTS to TACF of the network (BSC function). 

2.5.3.6.2.3.1.1.15 INTRA-BS DHO BRANCH ADDITION RESPONSE 

INFORMATION ELEMENT 

Figure 723 represents the format of the intra-BS DHO branch addition 
response information element. This information element may be included in the link 
setup response or link facility messages from BCFr of the BTS to TACF of the network 
(BSC function). 

2.5.3.6.2.3.1.1.16 ACCH SETUP RESPONSE INFORMATION ELEMENT 
Figure 724 represents the format of the ACCH setup response information 

element. This information element may be included in the link setup response or link 
facility messages from BCFr of the BTS to TACF of the network (BSC function). 
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2.5.3.6.2.3.1.1.17 INTRA-BS DHO BRANCH ADDITION REQUEST 

INFORMATION ELEMENT 

Figure 725 represents the format of the intra-BS DHO branch addition 
request information element. This information element may be included in the link 
facility message from TACF of the network (BSC function) to BCFr of the BTS. 

2.5.3.6.2.3.1.1.18 INTRA-BS DHO BRANCH DELETION REQUEST 

INFORMATION ELEMENT 

Figure 726 represents the format of the intra-BS DHO branch deletion 
request information element. This information element may be included in the link 
facility message from TACF of the network (BSC function) to BCFr of the BTS. 

2.5.3.6.2.3.1.1.19 INTRA-BS HHO INITIATION REQUEST 

INFORMATION ELEMENT 

Figure 727 represents the format of the intra-BS HHO initiation request 
information element. This information element may be included in the link facility 
message from TACF of the network (BSC function) to BCFr of the BTS. 

2.5.3.6.2.3.1.1.20 ACCH RELEASE REQUEST INFORMATION ELEMENT 
Figure 728 represents the format of the ACCH release request information 

element. This information element may be included in the link facility message from 
TACF of the network (BSC function) to BCFr of the BTS. 

2.5.3.6.2.3.1.1.21 FREQUENCY REPLACEMENT REQUEST 

INFORMATION ELEMENT WITHOUT FREQUENCY 
INDICATION 

Figure 729 represents the format of the frequency replacement request 
information element without frequency indication. This information element may be 
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included in the link facility message from TACF of the network (BSC function) to BCFr 
of the BTS. 

2.5.3.6.2.3.1.1.22 FREQUENCY REPLACEMENT REQUEST 

INFORMATION ELEMENT WITH FREQUENCY 
INDICATION 

Figure 730 represents the format of the frequency replacement request 
information element with frequency indication. This information element may be 
included in the link facility message from TACF of the network (BSC function) to BCFr 
of the BTS. 

2.5.3.6.2.3.1.1.23 SETUP COMPLETION NOTIFICATION INFORMATION 

ELEMENT 

Figure 731 represents the format of the setup completion information element. 
This information element may be included in the link facility message from TACF of 
the network (BSC function) to BCFr of the BTS. 

2.5.3.6.2.3.1.1.24 INTRA-BS HHO BRANCH DELETION RESPONSE 

INFORMATION ELEMENT 

Figure 732 represents the format of the intra-BS HHO branch deletion 
response information element. This information element may be included in the link 
facility message from BCFr of the BTS to TACF of the network (BSC function). 

2.5.3.6.2.3.1.1.25 INTRA-BS HHO BRANCH ADDITION RESPONSE 

INFORMATION ELEMENT 

Figure 733 represents the format of the intra-BS HHO branch addition 
response information element. This information element may be included in the link 
facility message from BCFr of the BTS to TACF of the network (BSC function). 



F0220/2551 



302 



2.5.3.6.2.3.1.1.26 ACCH RELEASE RESPONSE INFORMATION ELEMENT 
Figure 734 represents the format of the ACCH release response information 

element. This information element may be included in the link facility message from 
BCFr of the BTS to TACF of the network (BSC function). 

2.5.3.6.2.3.1.1.27 FREQUENCY REPLACEMENT SETUP RESPONSE 

INFORMATION ELEMENT WITH 
FREQUENCY INDICATION 

Figure 735 represents the format of the frequency replacement response 
information element with frequency indication. This information element may be 
included in the link facility message from BCFr of the BTS to TACF of the network 
(BSC function). ' 

2.5.3.6.2.3.1.1.28 FREQUENCY REPLACEMENT SETUP REQUEST 

INFORMATION ELEMENT WITH 
FREQUENCY INDICATION 

Figure 736 represents the format of the frequency replacement request 
information element with frequency indication. This information element may be 
included in the link facility message from BCFr of the BTS to TACF of the network 
(BSC function). 

2.5.3.6.2.3.1.1.29 FREQUENCY REPLACEMENT ACCEPTANCE 

INFORMATION ELEMENT WITHOUT 
FREQUENCY INDICATION 

Figure 737 represents the format of the frequency replacement acceptance 
information element without frequency indication. This information element may be 
included in the link facility message from BCFr of the BTS to TACF of the network 
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(BSC function). 

2.5.3.6.2.3.1.1.30 FREQUENCY REPLACEMENT RESPONSE 

INFORMATION ELEMENT WITHOUT 
FREQUENCY INDICATION 

Figure 738 represents the format of the frequency replacement response 
information element without frequency indication. This information element may be 
included in the link facility message from BCFr of the BTS to TACF of the network 
(BSC function). 

2.5.3.6.2.3.1.1.31 CODE REPLACEMENT REQUEST INFORMATION 

ELEMENT 

Figure 739 represents the format of the code replacement request information 
element. This information element may be included in the link facility message from 
BCFr of the BTS to TACF of the network (BSC function). 

2.5.3.6.2.3.1.1.32 TCH RELEASE REQUEST INFORMATION ELEMENT 
Figure 740 represents the format of the TCH release request information 

element. This information element may be included in the link release message from 
20 TACF of the network (BSC function) to BCFr of the BTS. 

2.5.3.6.2.3.1.1.33 SDCCH RELEASE REQUEST INFORMATION ELEMENT 
Figure 741 represents the format of the SDCCH release request information 

element. This information element may be included in the link release message from 
25 SACF and TACF of the network (BSC function) to SCMF of the BTS. 




2.5.3.6.2.3.1.1.34 CAUSE INFORMATION ELEMENT 

Figure 742 represents the format of the cause information element. 



This 
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information element may be included in the link release complete message from BCFr 
of the BTS to TACF of the network (BSC function), and from SCMF of the BTS to 
SACF and TACF of the network (BSC function). 

2.5.3.6.2.3.1.1.35 SDCCH SETUP REQUEST INFORMATION ELEMENT 
Figure 743 represents the format of the SDCCH setup request information 

element. This information element may be included in the link setup requested 
message from SCMF of the BTS to SACF and TACF of the network (BSC function). 

2.5.3.6.2.3.1.1.36 LAI SETUP REQUEST INFORMATION ELEMENT 
Figure 744 represents the format of the LAI setup request information 

element. This information element may be included in the link setup requested 
message from SCMF of the BTS to SACF and TACF of the network (BSC function). 

2.5.3.6.2.3.1.2 DEFINITIONS OF INFORMATION ELEMENTS OF BC 

ENTITY MESSAGES 
Next, definitions of information elements of BC entity messages will be 
described. 

2.5.3.6.2.3.1.2.1 PROTOCOL DISCRIMINATOR 

First, the protocol discriminator will be described. The protocol 
discriminator is formulated to distinguish the BC entity message from other messages 
used in the invented system and from other OSI network layer protocol unit messages 
encoded in accordance with another ITU-T recommendation, TTC recommendation, 
and another recommendation. The protocol discriminator is located at the first part 
of each BC entity message and encoded in the maimer shown in Figures 219 and 745. 

2.5.3.6.2.3.1.2.2 MESSAGE TYPE IDENTIFIER 

Next, the message type identifier will be described. The message type 
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identifier is formulated to identify the function of the BC entity message. The 
message type identifier is located at the second part of each BC entity message and 
encoded in the manner shown in Figures. 220 and 746. 



5 2.5.3.6.2.3. 1.2.3 LINK REFERENCE 

Next, the link reference will be described. The link reference is formulated to 
identify each instance of the BC protocol entity generated for AAL type 2/type 5 link 
for the TCH or SDCCH. The link reference is encoded in the manner shown in Figure 
221. 

10 In Figure 221, "flag" denotes an E/O flag. This flag indicates zero when the 

message is sent from the device which has generated the link reference. This flag 
indicates one when the message is sent to the device which has generated the link 
reference. Octet 2 and later octets are extended according to the value of the used 
link reference. 

15 

2.5.3.6.2.3.1.2.4 INFORMATION ELEMENT IDENTIFIER 

Next, the information element identifier will be described. The information 
element identifier is formulated to identify an optional information element included 
in the BC entity message. The information element identifier is encoded in the 
20 manner shown in Figure 222. 

2.5.3.6.2.3.1.2.5 LENGTH OF INFORMATION ELEMENT 

Next, the "length of information element" will be described. The length of 
information element is formulated to indicate the whole length of all of parameters in 
25 the fundamental information element. The length of information element is encoded 
in the manner shown in Figure 223. 
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2.5.3.6.2.3.1.2.6 AAL TYPE AND LINK IDENTIFIER 

The M AAL type" indicates the AAL type and is encoded in the manner shown in 
Figure 224. It indicates AAL type 2 when it is encoded as "0010." It indicates AAL 
type 5 when it is encoded as "0101." 
5 An example of encoded link identifier is represented in Figure 225. In Figure 

225, the size of VPCI and the size of VCI (virtual channel identifier) comply with the 
standard cell of the ATM specification in connection with the UNI (user-network 
interface). One type of VPCI indicating zero is used in the invented system, but 16 or 
more types of VPCI of which the length is 4 or more bits may be used in commercial 
10 application. VCI is 256/VPCI and UCI is 256/VCI. 

2.5.3.6.2.3.1.2.7 TRANSMISSION QUALITY 

Next, the "transmission quality" will be described. The transmission quality 
indicates the quality of ATM link and is encoded in the manner shown in Figure 226. 
15 In the field of the transmission quality of one octet, the length of the acceptable delay 
may be three bits, the length of the cell loss rate may be three bits, and the reserved 
bits may be two bits according to the invented system. 

2.5.3.6.2.3.1.2.8 FORWARD (DOWNLINK) TRANSMISSION RATE 

20 Next, the "forward or downlink transmission rate" will be described. The 

forward transmission rate indicates the forward information transmission rate. In 
the invented system, the forward transmission rate is selected from the group 
consisting of 8 kbps, 12.8 kbps, 32 kbps, 34.4 kbps, 64 kbps, 76.8 kbps, 128 kbps, 162.4 
kbps, and 384 kbps. 

25 

2.5.3.6.2.3.1.2.9 REVERSE (UPLINK) TRANSMISSION RATE 

Next, the "reverse or uplink transmission rate" will be described. The 
reverse transmission rate indicates the reverse information transmission rate. In the 
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invented system, the reverse transmission rate is selected from the group consisting of 
8 kbps, 12.8 kbps, 32 kbps, 34.4 kbps, 64 kbps, 76.8 kbps, 128 kbps, 162.4 kbps, and 
384 kbps. 



5 2.5.3.6.2.3.1.2.10 SECTOR NUMBER 

Next, the "sector number" will be described. The sector number is a value of 
1-12 for identifying the corresponding sector in the BTS and is encoded in the manner 
shown in Figure 227. 

10 2.5.3.6.2.3.1.2.11 BEARER CAPABILITY 

Next, the "bearer capability" will be described. The bearer capability is 
encoded in the manner represented in Figure 228 and may indicate voice service, 
packet service, or unrestricted digital service. 

15 2.5.3.6.2.3.1.2.12 FREQUENCY SELECTION INFO. 

Next, the "frequency selection information" will be described. The frequency 
selection information is an information element of 0-255 indicating frequency bands 
which may be employed by the mobile station and is sent from the mobile 
communications switching center to the base station when the base station should 

20 select the communication frequency. Upon reception of the frequency selection 
information, the base station selects the most appropriate frequency band which may 
be employed by the base station and mobile station. The frequency selection 
information is encoded in the manner represented in Figure 229. 

25 2.5.3.6.2.3.1.2.13 FREQUENCY 

Next, the "frequency" will be described. The frequency information element 
indicates the frequency band selected by . the base station. Simultaneous link 
connections for the same mobile station may use the same frequency band. The 
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frequency information element which indicates one of fl to f256 is encoded in the 
manner represented in Figure 230. 

2.5.3.6.2.3.1.2.14 FRAME OFFSET GROUP 

Next, the "frame offset group" will be described. The frame offset group 
indicates which time slot in a single radio frame should be the front end of the logical 
frame when the mobile station communicates. This is formulated to uniformize 
traffic in a single frame time unit within the wired path. "Frame offset group" takes a 
value of 0-15 and is encoded in the manner represented in Figure 231. 

2.5.3.6.2.3.1.2.15 SLOT OFFSET GROUP 

Next, the "slot offset group" will be described. The slot offset group indicates 
an offset value of downlink transmission timing for a short code. The downlink 
transmission timing may be offset by, at most, 15 subslots in order to reduce 
redundancy of pilot symbols. The offset value is acquired at the BTS when the first 
call occurs, is stored by the BSC function of the network, and is included in the slot 
offset group information element. The indication by the slot offset group at the first 
call should be contained until the release of all calls of the mobile station. The slot 
offset group is encoded in the manner shown in Figure 232. 

2.5.3.6.2.3.1.2.16 LONG CODE PHASE DIFFERENCE 

Next, the "long code phase difference" will be described. The long code phase 
difference indicates the difference between the long code phase calculated by a long 
code counter (SFN) for the visited perch channel or the uplink long code phase of the 
in-use sector and the long code phase calculated by a long code counter (SFN) for the 
perch of the surrounding sector (handover destination sector) represented in chip time. 
This is used when the execution of DHO and the zone selection at call attempt or 
acceptance. The long code phase is measured by the mobile station, and reported to 
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the BSC of the network. The long code difference should be within the range between 
zero and 2 - 1 chip time and be encoded in the manner represented in Figure 233. 
When the long code phase difference is in excess of 128 chip time, the field should be 
extended with extension bits. 

2.5.3.6.2.3.1.2.17 REVERSE LONG CODE NUMBER 

Next, the "reverse or uplink long code number" will be described. The in-use 
reverse long code number is a specific information to the mobile station. The 
information can be utilized continuously although the frequency band has been 
updated. The reverse long code number is encoded in the manner represented in 
Figure 234. 

2.5.3.6.2.3.1.2.18 REVERSE SHORT CODE TYPE 

Next, the "reverse or uplink short code type" will be described. The reverse 
short code type is encoded in the manner represented in Figure 235. 

2.5.3.G.2.3. 1.2.19 NUMBER OF REVERSE SHORT CODES 

Next, the "number of reverse or uplink short codes" will be described. The 
number of reverse short codes indicates the number of reverse short codes when a 
plurality of reverse short codes are used for a reverse channel of one connection. The 
number of reverse short codes is encoded in the manner represented in Figure 236. 

2.5.3.6.2.3.1.2.20 REVERSE SHORT CODE NUMBER 

Next, the "reverse or uplink short code number" will be described. The 
reverse short code number is a value of 0-1023 for identifying the employed reverse 
short code. This is a unique number for distinguishing the corresponding short code 
from others which are used for the same mobile station although a single long code is 
used for the mobile station. At the first reverse short code number field, the short 
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code number for the ACCH is contained. When VPCI, VCI, and UCI for ACCH has 
been designated simultaneously, the BTS recognizes that the ACCH is necessary to be 
established. The reverse short code number is encoded in the manner represented in 
Figure 237. 

5 

2.5.3.6.2.3.1.2.21 FORWARD SHORT CODE TYPE 

Next, the "forward or downlink short code type" will be described. The 
forward short code type is encoded in the manner represented in Figure 238. 

10 2.5.3.6.2.3.1.2.22 NUMBER OF FORWARD SHORT CODES 

Next, the "number of forward or downlink short codes" will be described. The 
number of forward short codes indicates the number of forward short codes when a 
plurality of forward short codes are used for a forward channel of one connection. The 
number of forward short codes is encoded in the manner represented in Figure 239. 

15 

2.5.3.6.2.3.1.2.23 AAL TYPE AND LINK IDENTIFIER FOR ACCH 

The "AAL type" for the ACCH indicates the AAL type. It is always encoded 
as "0010" for indicating AAL type 2 and is encoded in the manner shown in Figure 240. 
An example of encoded link identifier for the ACCH is represented in Figure 
20 241. The link identifier and TCH may be different. 

2.5.3.6.2.3.1.2.24 TRANSMISSION QUALITY FOR ACCH 

Next, the "transmission quality" for the ACCH will be described. The 
transmission quality indicates the quality of ATM link and is encoded in the manner 
25 shown in Figure 242. In the field of the transmission quality of one octet, the length 
of the acceptable delay may be three bits, the length of the cell loss rate may be three 
bits, and the reserved bits may be two bits according to the invented system. 
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2.5.3.6.2.3.1.2.25 FORWARD TRANSMISSION RATE FOR ACCH 

Next, the "forward or downlink transmission rate" for the ACCH will be 
described. The forward transmission rate indicates the forward information 
transmission rate which is restricted by the code used for the TCH. In the invented 
system, the forward transmission rate is selected from the group consisting of 8 kbps, 
12.8 kbps, 32 kbps, 34.4 kbps, 64 kbps, 76.8 kbps, 128 kbps, 162.4 kbps, and 384 kbps. 

2.5.3.6.2.3.1.2.26 REVERSE TRANSMISSION RATE FOR ACCH 

Next, the "reverse or uplink transmission rate" for the ACCH will be described. 
The reverse transmission rate indicates the reverse information transmission rate. 
In the invented system, the reverse transmission rate is selected from the group 
consisting of 8 kbps, 12.8 kbps, 32 kbps, 34.4 kbps, 64 kbps, 76.8 kbps, 128 kbps, 162.4 
kbps, and 384 kbps. 

2.5.3.6.2.3.1.2.27 FORWARD SHORT CODE NUMBER 

Next, the "forward or downlink short code number" will be described. The 
forward short code number is a value of 0-1023 for identifying the employed forward 
short code. This is a unique number for distinguishing the corresponding short code 
from others which are used for the same mobile station although a single long code is 
used for the mobile station. The forward short code number is encoded in the manner 
represented in Figure 243. 

2.5.3.6.2.3.1.2.28 RESULT 

The "result" is formulated for indicating the result, i.e., OK or NG and is 
encoded in the manner represented in Figure 244. 



2.5.3.6.2.3.1.2.29 CAUSE 

Next, the "cause" will be described. When the link release complete message 
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is the first link reference release message, this information element is mandatory. If 
the link release complete message is transmitted as a result of an error treatment 
condition, this information element is included. The cause is encoded in the manner 
represented in Figure 245. 

2.5.3.6.2.3.1.2.30 INITIAL TRANSMISSION POWER 

Next, the "initial transmission power" will be described. The initial 
transmission power indicates the downlink transmission power and is encoded in the 
manner represented in Figure 246. 

2.5.3.6.2.3.1.2.32 LOCATION IDENTITY 

Next, the "location identity" will be described. The location identity is 
utilized for identifying the location registration area where the mobile station visits. 
This takes a value between zero and 255 and is encoded in the manner represented in 
Figure 247. 

2.5.3.6.3.2 FORMATS OF INFORMATION ELEMENTS OF BSM 

ENTITY MESSAGES 
Next, the formats of information elements of BSM entity messages will be 
described. 

2.5.3.6.3.2. 1 PROTOCOL DISCRIMINATOR 

First, the protocol discriminator will be described. The protocol 
discriminator is formulated to distinguish the BSM entity message from other 
messages used in the invented system and from other OSI network layer protocol unit 
messages encoded in accordance with another ITU-T recommendation, TTC 
recommendation, and another recommendation. The protocol discriminator is located 
at the first part of each BSM entity message and encoded in the manner shown in 
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Figures 248 and 747. 

2.5.3.6.3.2.2 MESSAGE TYPE IDENTIFIER 

Next, the message type identifier will be described. The message type 
5 identifier is formulated to identify the function of the BC entity message. The 
message type identifier is located at the second part of each BC entity message and 
encoded in the manner shown in Figures 249 and 748. 

2.5.3.6.3.2.3 PCHs CALCULATION INFORMATION 

10 Next, the "PCHs calculation information" will be described. The "PCHs 

Calculation Information" is an information element for the BTS to select the perch 
channel. This information element is, for example, represented at inferior 16 bits of 
the binary encoded IMUI. That is, the PCHs calculation information can be 
recognized by a part of the IMUI of each mobile station. This is encoded in the 

15 manner represented in Figure 250. 

2.5.3.6.3.2.4 ' AREA NUMBER 

Next, the "area number" will be described. The area number is utilized for 
identifying the location registration area where the mobile station visits. This takes a 
20 value between zero and 255 and is encoded in the manner represented in Figure 251. 

2.5.3.6.3.2.5 PAGED MS ID 

Next, the "paged MS ID" will be described. The paged MS ID is the TMUI or 
IMUI for paging the subject mobile station. If the IMUI is used as the paged MS ID, 
25 the integer IMUI transformed from the IMUI coded with BCD. The paged MS ID is 
encoded in the manner represented in Figure 252. 
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2.5.3.6.3.2.5.1 NUMBER TYPE 

The "number type" indicates the type of number which is included at octet 4 
and later octets in the paged MS ID. The number type is encoded in the manner 
represented in Figure 749. 

5 

2.5.3.6.3.2.5.2 NUMBER LENGTH 

The "number length" indicates the length, represented in octets, of number 
which is included at octet 4 and later octets in the paged MS ID. The number length 
is encoded in the manner represented in Figure 750. The number length does not 
10 include the total length of octets 1-3 of the paged MS ID. 

2.5.3.6.3.2.5.3 TMUI 

Next, the "TMUI information element" will be described. The TMUI is used 
for identifying the mobile station. The TMUI is updated whenever the area 
15 registration or updating thereof is carried out. This is dynamically allotted to the 
mobile station. The length of the TMUI information element is fixed to four octets. 

2.5.3.6.3.2.5.4 INTEGER IMUI 

Next, the "integer IMUI" will be described. The integer IMUI is used for 
20 identifying the mobile station. The IMUI is used in the second paging when the 
network has recognized that the TMUI stored in the mobile station replying to the first 
paging with TMUI is wrong. The integer IMUI is transformed from the IMUI coded 
with BCD, and has a variable length, at most, seven octets. 

25 2.5.3.6.3.2.5.4 PAGING ID 

Next, the "paging ID" will be described. The paging ID is used for managing 
the paging call when paging the mobile station. The paging ID is temporally allotted 
when paging. The paging ID information element is encoded in the manner 



F0220/2551 



315 



represented in Figure 253. 



2.5.3.6.4.1 



SDL DIAGRAMS FOR BC 



To supplement the above description, various SDL diagrams for bearer control 
are represented in Figures 255 through 258. Figure 255 represents an SDL diagram 
for bearer control in the SDCCH executed in the BSC function of the network. Figure 
256 represents an SDL diagram for bearer control in the TCH/ACCH executed in the 
BSC function of the network. Figure 257 represents an SDL diagram for bearer 
control in the SDCCH executed in the BTS. Figure 258 represents an SDL diagram 
for bearer control in the TCH/ACCRexecuted in the BTS. 

2.5.3.6.4.2 SDL DIAGRAM FOR BSM 

In addition, Figure 254 represents an SDL diagram for base station 
management. 

3 CONTROL PROCEDURES UNIQUELY CARRIED OUT BY THE 

INVENTED SYSTEM 

The invented system can carry out unique control procedures which cannot be 
achieved by prior arts since it uses the above-described structures and protocol 
specifications. Such unique control procedures will be described hereinafter. 



As described above, if the ciphering onset moment is not recognized, the 
destination device cannot decipher the ciphered signal (control signal) although it has 
received the ciphered signal. That is, if the onset time of the decipherment may be 
misestimated, the meaning of signals cannot be made out. 

In a solution of the above-described problem, it is possible that after the 
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3.1.1 



BACKGROUND OF INVENTION OF THE PROCEDURE 
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transmission of an enciphering onset request from the network to the mobile station, 
the network and the mobile station commence to encipher transmitted signals and to 
decipher received signals. 

This solution method will be described in more detail with reference to 
> Figures 755 and 756. Figure 755 represents a ciphering procedure sequence diagram 
in normal operation where the network and the mobile station commence to encipher 
transmitted signals and to decipher received signals after the transmission of an 
enciphering onset request from the network to the mobile station. In the initial stage, 
assume that the transported signals between the mobile station and network are not 
ciphered. 

As represented in Figure 755, the network (NW) notifies the mobile station 
(MS) of the enciphering onset request at step S21. After the notification of the 
enciphering onset request, the network commences to encipher transmitted signals 
and to decipher received signals at step S22. 

Upon reception of the enciphering onset request, the mobile station also 
commences to encipher transmitted signals and to decipher received signals at step 
S23. Thereafter, the network and the mobile station encipher transmitted signals 
and decipher received signals. 

However, in the above-described prior art ciphering procedure sequence, there 
is likelihood of failure of decipher because of the difference between the time when the 
source device commences to encipher the transmitted signal and the time when the 
destination device commences to decipher the received signal. 

For example, as represented in Figure 756, although the network has 
transmitted the enciphering onset request at step S24, assume that the mobile station 
has transmitted at step S25 a call release request for disconnect the call to the network 
before the reception of the enciphering onset request at the mobile station. In this 
case, when the network receives the non-ciphered call release request at the reception 
time Tx, the network has already been prepared to decipher the received signal at step 
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S26. If the network does not have the function to recognize both of enciphered and 
non-ciphered signals at the same mode —this kind of network is usual for system 
simplification—, it cannot read the non-ciphered call release request, so that the 
procedure is blocked. 

It is therefore an object of the present invention to provide a control method 
for a mobile station, network, and mobile communication system to read received 
signals with the least amount of failure by means of the ciphering onset at the source 
simultaneously with the deciphering onset at the destination. 

3. 1.2 OUTLINE OF THE CIPHERING ONSET MOMENT 

NOTIFICATION OF EMBODIMENT 

The outline of ciphering onset moment notification according to an 
embodiment of the present invention will be described. Figure 757 represents a 
ciphering procedure sequence diagram in normal operation according to the 
embodiment. In the initial stage, assume that the transported signals between the 
mobile station and network are not ciphered. 

As represented in Figure 757, the network (NW) notifies the mobile station 
(MS) of the enciphering onset request at step S31. After the notification of the 
enciphering onset request, the network commences to encipher transmitted signals 
(downlink or forward signals) at step S32. 

Upon reception of the enciphering onset request, the mobile station 
commences to decipher received signals at step S33. Thereafter, the network 
enciphers transmitted signals while the mobile station deciphers received signals. 

Furthermore, the mobile station sends the network the enciphering onset 
response for acknowledging the enciphering onset request at step S34. After the 
notification of the enciphering onset response, the mobile station commences to 
encipher transmitted signals (uplink or reverse signals) at step S35. 

Upon reception of the enciphering onset response, the network commences to 
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decipher received signals at step S36. 

Accordingly, the mobile station does not commence deciphering the received 
signal until it receives the ciphering onset request. Similarly, the network does not 
commence deciphering the received signal until it receives the ciphering onset 
5 response. Therefore, the destination device can read received signals with the least 
amount of failure by means of the ciphering onset at the source simultaneously with 
the deciphering onset at the destination. 

For example, as represented in Figure 758, assume that the network has 
transmitted the enciphering onset request at step S37, and that the mobile station has 

10 transmitted at step S38 a call release request for disconnect the call to the network 
before the reception of the enciphering onset request at the mobile station. In this 
case, when the network receives the non-ciphered call release request at the reception 
time Txl, the network has not yet been prepared to decipher the received signal at step 
S39 although it has been prepared to encipher the transmitted signal. Therefore, 

15 although the network does not have the function to recognize both of enciphered and 
non-ciphered signals at the same mode —this kind of network is usual for system 
simplification—, it can read the non-ciphered call release request smoothly. 

3.1.3 DETAILED DESCRIPTION OF THE CIPHERING ONSET 

20 MOMENT NOTIFICATION OF EMBODIMENT 

The ciphering onset moment notification of embodiment will be further 
described in more detail. With reference to the functional model in Figure 64, the 
encipherment onset moment notification procedures will be described. As shown in 
Figure 64, the mobile station MS includes functional entities called UIMF, MCF, and 
25 TACAF. UIMF stores information on the station user and serves the user 
authentication and encipherment calculation. MCF functions as an interface with 
the network for realizing services that are not related to calls. TACAF controls the 
access processes to the mobile station terminal, e.g., the origination, paging, and so on. 
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The network on the other hand includes functional entities called SACF, 
TACF, LRCF, and LRDF. SACF is connected with MCF to function as an interface 
with the mobile terminal for realizing services that are not related to calls. TACF is 
connected with TACAF to control the access processes to the mobile station terminal, 
5 e.g., the origination, paging, and so on. LRCF is connected with TACF and SACF to 
control mobility management. LRDF stores various data on mobility management 

With such a structure, prior to the mutual notification of the encipherment 
onset, a user authentication procedure (refer to section 2.4.5.1) is executed as shown in 
Figure 63. In execution of the user authentication procedure, a certified 
^ 10 encipherment key is previously stored at UIMF and LRDF of the network and mobile 

=E terminal and delivered to TACAF, MCF, TACF, and SACF. 

£3 

hi Then, mutual notification of the encipherment onset time is carried out in 

[a accordance with the sequence shown in Figure G5. More specifically, first, LRCF of 

s a the network sends a START CIPHERING request indication for indicating that the 

lf s 15 network will start encipherment to TACAF and MCF of the mobile terminal via TACF 

|4 and SACF of the network. Consequently, the mobile terminal can recognize that the 

S3 succeeding signals transmitted from the network will be ciphered. After the 

transmission of the START CIPHERING request indication, TACF and SACF of the 
network cipher succeeding signals according to a preselected encipherment procedure 
20 using a preselected ciphering key. Once the mobile terminal receives the enciphered 
signal, TACAF and MCF controls the decipherment of the received signals. In 
advance to the decipherment, TACAF and MCF receive the encipherment key from 
UIMF to carry out the decipherment. Accordingly, the downlink signal transmitted 
from the network can be transported in secret and interpreted by only the mobile 
25 terminal. 

Next, TACAF and MCF of the mobile terminal send a START CIPHERING 
response confirmation to TACF and SACF of the network, this confirmation indicating 
that mobile station will next start to transmit enciphered signals. Consequently, the 
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network entities can recognize that the succeeding signals transmitted from the 
mobile terminal will be ciphered. After the transmission of the START CIPHERING 
response confirmation, TACAF and MCF of the mobile terminal cipher succeeding 
signals according to a preselected encipherment procedure using a preselected 
5 ciphering key. Once the terminal entities receive the enciphered signal, TACF and 
SCF decipher the received signals. Accordingly, the uplink signal transmitted from 
the mobile terminal can be transported in secret and interpreted by only the network. 

Therefore, although the network does not have the function to recognize both 
of enciphered and non-ciphered signals at the same mode for system simplification, 
10 communications can be achieved between the mobile station and the network smoothly 
with the least amount of failure by means of the ciphering onset at the source 
simultaneously with the deciphering onset at the destination. 

3.2 SELECTION OF ENCIPHERMENT MANNER BY NEGOTIATION 

15 BETWEEN MOBILE STATION AND NETWORK 

3.2. 1 BACKGROUND OF INVENTION OF THE PROCEDURE 

Figure 759 is a schematic sequence diagram representing an encipherment 
method in a mobile communications system, in which only one specific encipherment 
manner is adopted. In this mobile communications system, once a mobile station 
20 (MS) requests to communicate with the network (NW) at step S41, it is necessary to 
carry out during the communications (at step S42) the specific encipherment manner 
including only one specific encipherment procedure or the combination of only one 
specific encipherment procedure and an encipherment key preparation procedure. 

In this system, if the user of the mobile station would like to select a level of 
25 security, it is impossible to select a suitable encipherment procedure or a suitable 
encipherment key preparation procedure. 

In addition, it is impossible for the mobile station or the network to select a 
suitable encipherment procedure or a suitable encipherment key preparation 
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procedure for multimedia service, such as transmission of voice or motion pictures 
although the communications system permits to transmit them. 

Furthermore, if it is necessary to improve encipherment in view of function 
extension, such as a new service, of the mobile communications system in the future, it 
5 will be difficult to adopt a new suitable encipherment procedure or a new suitable 
encipherment key preparation procedure. 

Furthermore, it is necessary that various mobile communications networks 
utilize all of the encipherment procedures in common in order that mobile stations 
roam across service areas of mobile communications networks. 
10 It is therefore an object of the present invention to provide a control method 

for a mobile station, network, and mobile communication system to deal flexibly 
various encipherment procedures and encipherment key preparation procedures. A 
preferable embodiment will be described next with reference to Figures 760 through 
762. 

15 

3.2.2 OUTLINE OF SELECTION OF THE ENCIPHERMENT MANNER 

BY NEGOTIATION BETWEEN MOBILE STATION AND 
NETWORK IN ACCORDANCE WITH EMBODIMENT 
Figure 760 represents a schematic sequence diagram representing the 
20 selection of encipherment manner by negotiation between mobile station and network 
in accordance with an embodiment. First, the mobile station (MS) requests to 
communicate with the network (NW) at step S51. Simultaneously, the mobile station 
notifies the network of types of encipherment manners which can be executed by the 
mobile station. The encipherment manners may include only encipherment 
25 procedures or encipherment procedures and encipherment key preparation procedures 
although Figure 760 illustrates types of encipherment procedures A, B, and C. 

In view of the notification from the mobile station, the network selects a type 
of encipherment manner at step S52. For example, a type of encipherment procedure 
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A is selected in Figure 760. Prior to encipherment communication, the network sends 
the mobile station an encipherment onset request indicating the selected type of 
encipherment manner at step S53. 

The mobile station then adapts the inside functions according to the type of 
5 encipherment manner (encipherment procedure A in Figure 760) selected by the 
network at step S54. The network also adapts the inside device functions according 
to the type of encipherment manner (encipherment procedure A in Figure 760) selected 
by the network at step S55. 

Accordingly, the mobile station and network are allowed to communicate with 
10 each other at step S56 in such a fashion that they use the selected encipherment 
manner (e.g., encipherment procedure A in Figure 760). Therefore, if the user of the 
mobile station would like to select a level of security, it is possible to select a suitable 
encipherment procedure or a suitable encipherment procedure and a suitable 
encipherment key preparation procedure. 
15 In addition, it is possible for the mobile station or the network to select a 

suitable encipherment procedure or a suitable encipherment key preparation 
procedure for multimedia service, such as transmission of voice or motion pictures if 
the communications system permits to transmit them. 

Furthermore, if it is necessary to improve encipherment in view of function 
20 extension, such as a new service, of the mobile communications system in the future, it 
will be easy to adopt a new suitable encipherment procedure or a new suitable 
encipherment key preparation procedure. 

Furthermore, if a plurality of mobile communications networks utilize 
mimimal encipherment manners in common, it is possible to communicate under a 
25 suitable encipherment manner when mobile stations roam across service areas of 
mobile communications networks. It is unnecessary that various mobile 
communications networks utilize all of the encipherment procedures in common: each 
communications network can execute other unique encipherment procedures. 
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3.2.3 



DETAILED DESCRIPTION OF THE SELECTION OF 



ENCIPHERMENT MANNER BY NEGOTIATION BETWEEN 



MOBILE STATION AND NETWORK IN EMBODIMENT 



The selection of encipherment manner by negotiation between mobile station 
and network in accordance with an embodiment will be further described in more 
detail with reference to the sequential diagram constituted of Figures 761 and 762. 
In the following description, an encipherment procedure and an encipherment key 
preparation procedure are selected at the selection of the encipherment manner. In 
Figures 761 and 762, only parameters involved in the encipherment are illustrated 
and parameters only involved in the authentication are not illustrated for simplifying 
the description of the encipherment. 

A security control unit of the mobile station decides an order of priorities of the 
types of the encipherment procedures which can be executed by the mobile station and 
an order of priorities of the types of the encipherment key procedures which can be 
executed by the mobile station at step S61 before encipherment communication. The 
security control unit of the mobile station sends a security control unit of the network a 
call setup request at step S62. The call setup request includes information on the 
types of encipherment procedures A, B, and C which can be executed by the mobile 
station; the types of encipherment key preparation procedures X, Y, and Z which can 
be executed by the mobile station; and the priority order. Upon the reception, the 
security control unit of the network stores the information on the types of 
encipherment procedures A, B, and C at step S63. 

Next, the security control unit of the network notifies a user information 
control unit of the network of the information on the types of encipherment key 
preparation procedures X, Y, and Z at step S64. Upon the reception, the user 
information control unit prepares a random number at step S65. Furthermore, the 
user information control unit selects an encipherment key preparation procedure from 
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the key preparation procedures X, Y, and Z at step S66. 

Then, the user information control unit prepares an encipherment key at step 
SG7 in accordance with the random number prepared at step S65 and the type of 
encipherment key preparation procedure (e.g., X as in Figure 761) selected at step S66. 
5 Subsequently, the user information control unit transfers the prepared random 
number, the prepared encipherment key, and the selected type of encipherment key 
preparation procedure (e.g., X as in Figure 761) as authentication information to the 
security control unit at step S68. 

Then, the security control unit of the network stores the prepared 

10 encipherment key at step S69, and transmits an authentication request indicating the 
prepared random number and the selected type of encipherment key preparation 
procedure (e.g., X as in Figure 761) to the security control unit of the mobile station at 
step S70. In the transmission at step S70, other parameters for authentication 
calculation are included in the authentication request. 

15 Upon the reception of the authentication request, the security control unit of 

the mobile station sends an authentication calculation request indicating the random 
number and the type of encipherment key preparation procedure (e.g., X as in Figure 
761) to a user information control unit of the mobile station at step S71. 

Upon the reception of the authentication calculation request, the user 

20 information control unit of the mobile station prepares another encipherment key at 
step S72 in accordance with the random number and the type of encipherment key 
preparation procedure (e.g., X as in Figure 761). As represented in Figure 762, the 
user information control unit sends the security control unit of the mobile station an 
authentication calculation result indicating the prepared encipherment key at step 

25 S74. 

Then, the security control unit of the mobile station stores the encipherment 
key prepared at the user information control unit of the mobile station at step S75. In 
addition, the security control unit notifies at step S76 the security control unit in the 
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network of an authentication response including the authentication calculation result 
obtained by a calculation at the user information control unit. 

Upon the reception of the authentication response, the security control unit of 
the network sends the user information control unit of the network at step S77 an 
authentication calculation comparison request indicating the authentication 
calculation result sent from the mobile station. The user information control unit, 
then, compares the authentication calculation result with another authentication 
calculation result prepared at the network in accordance with the encipherment key 
prepared at step S67 and other parameters for authentication (not illustrated). 

After the completion of the authentication, the user information control unit of 
the network can send an encipherment request to the security control unit of the 
network at step S78. 

Upon the reception of the encipherment request, the security control unit of 
the network transmits at step S79 another encipherment request indicating the 
encipherment key stored at step S69 and the types of encipherment procedures A, B, 
and C stored at step S63 to a radio access control unit of the network. 

Then, the radio access control unit of the network selects an encipherment 
procedure from the procedures A, B, and C at step S80. For example, the type of 
procedure B is selected in Figure 762. The radio access control unit in the network 
sends another encipherment request indicating the selected type of encipherment 
procedure (B) to a radio access control unit of the mobile station at step S81. 

Upon the reception of the encipherment request, the radio access control unit 
of the mobile station stores the indicated type of encipherment procedure (B) at step 
S82. In addition, the radio access control unit of the mobile station requests at step 
S83 the security control unit of the mobile station to read the encipherment key which 
was stored at step S75. In response, the security control unit of the mobile station 
notifies the radio access control unit of the stored encipherment key at step S84. 

Then, the radio access control unit of the mobile station sends an 
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encipherment response to the radio access control unit of the network at step S85. 
The encipherment response indicates that the mobile station will encipher messages to 
be sent in accordance with the type of encipherment procedure (B) selected at the 
network and the encipherment key prepared at the mobile station. Afterward, at step 
S86, the radio access control unit starts communication in such a manner that the 
encipherment is carried out. Upon the reception of the encipherment response, at 
step S87, the radio access control unit of the network starts communication in such a 
manner that the encipherment is carried out according to the type of encipherment 
procedure (B) and the encipherment key prepared at the network. 

According to the above -described method, if the user of the mobile station 
would like to select a level of security, it is possible to select a suitable encipherment 
procedure or a suitable encipherment procedure and a suitable encipherment key 
preparation procedure. 

In addition, it is possible for the mobile station or the network to select a 
suitable encipherment procedure or a suitable encipherment key preparation 
procedure for multimedia service, such as transmission of voice or motion pictures if 
the communications system permits to transmit them. 

Furthermore, if it is necessary to improve encipherment in view of function 
extension, such as a new service, of the mobile communications system in the future, it 
will be easy to adopt a new suitable encipherment procedure or a new suitable 
encipherment key preparation procedure. 

Furthermore, if a plurality of mobile communications networks utilize 
minimal encipherment manners in common, it is possible to communicate under a 
suitable encipherment manner when mobile stations roam across service areas of 
mobile communications networks. It is unnecessary that various mobile 
communications networks utilize all of the encipherment procedures in common: each 
communications network can execute other unique encipherment procedures. 
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3.3 START OF DIVERSITY HANDOVER SIMULTANEOUSLY WITH 

ACCESS LINK SETUP 
3.3.1 BACKGROUND OF INVENTION OF THE PROCEDURE 

Start of diversity handover and a setup of an access link are originally 
5 different procedures from each other. Therefore, in a conventional usual method, 
when a mobile station starts communicating, an access link for the mobile station is 
setup first. Then, when diversity handover is necessary by travelling of the mobile 
station or another reason, diversity handover is carried out. 

However, the mobile station often locates at the position where diversity 
10 handover can be carried out when the access link is setup. Even in such a case, 
O diversity handover transition and the access link setup are carried out at different 

=p times in the conventional method. 

1=^ For example, as represented in part (a) of Figure 763, a base station 21 has 

q radio zones 11 and 12 and a mobile station 10 locates at a diversity handover zone 13 

fjj 15 where the radio zones 11 and 12 overlap each other. In this state, when a call attempt 

2^ is originated to or from the mobile station 10, an access link with minimal components 

W for facilitating communication of the mobile station 10 are setup. For example, a 

radio access link 41 is established between the mobile station 10 and the base station 

21 while a wired access link 51 is established between the base station 21 and a base 
20 station controller 30. After finish of the access link setup, a step for transiting intra- 

cell diversity handover is carried out: a radio access link 42 corresponding to the radio 
zone 12 is added as represented in part (b) of Figure 763. 

Additionally, the mobile station often locates at the position where inter-cell 
diversity handover can be carried out when the access link is setup. For example, as 
25 represented in part (a) of Figure 764, the mobile station 10 locates at a diversity 
handover zone 15 where radio zones 11 and 14 corresponding to base stations 21 and 

22 overlap each other. In this state, when a call attempt is originated to or from the 
mobile station 10, an access link with minimal components for facilitating 
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communication of the mobile station 10 are setup. For example, a radio access link 41 
corresponding to the radio zone 11 is established between the mobile station 10 and 
the base station 21 while a wired access link 51 is established between the base station 
21 and a base station controller 30. After finish of the access link setup, a step for 
transiting inter-cell diversity handover is carried out: a radio access link 44 
corresponding to the radio zone 14 is added and a wired access link 52 is additionally 
established between the base station 22 and the base station controller 30. 

As discussed above, although it is possible to carry out diversity handover at 
the access link setup, these procedures are carried out at different times: the access 
link setup should be carried out first, and then diversity handover should be carried 
out in accordance with prior art. 

The access link setup needs a series of information flows transported between 
the mobile station and the network as illustrated in Figure 765. In addition, in order 
to transit to intra-cell diversity handover, needed is a series of information flows 
transported between the mobile station and the network as illustrated in Figure 766. 
In addition, in order to transit to inter-cell diversity handover, needed is a series of 
information flows transported between the mobile station and the network as 
illustrated in Figure 767. The information flows shown in Figures 765 to 767 have 
been already described and will be described for explanation of the invented control 
method. Thus, the description is omitted here. 

According to the above circumstances, a large number of control signals are 
transported between the mobile station and the network and within the network after 
the call attempt before diversity handover. Consequently, the system should endure 
its enormous control burden. 

In addition, since the mobile station can use only a single radio access link 
directly after the access link setup, the transmission power for this access link is 
strong so as to enlarge interference levels at other radio access links. Therefore, the 
capacity or the number of channels at the cell may be decreased. The control method 
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described below will resolve the above-mentioned problems. 



3.3.2 OUTLINE OF THE CONTROL METHOD OF EMBODIMENT 

In the invented system, the network facilitates diversity handover of a mobile 
5 station simultaneously with the access link setup for the mobile station upon a call 
attempt to or from the mobile station when the mobile station is in a status where it 
can carry out diversity handover. In addition, the mobile station starts diversity 
handover simultaneously with the access link setup. More specifically, upon the call 
attempt, at least one auxiliary branch are established for facilitating diversity 
10 handover in addition to the establishment of the main branch, thereby enabling the 
mobile station to commence the diversity handover using the plurality of branches. 

Part (a) of Figure 768 represents one feature of the invented system which for 
starting inta-cell diversity handover simultaneously with the access link setup. Part 
(b) of Figure 768 represents one feature of the invented system for starting inter-cell 
15 diversity handover simultaneously with the access link setup. 

3.3.2.1 START OF INTRA-CELL DIVERSITY HANDOVER 

SIMULTANEOUSLY WITH THE ACCESS LINK SETUP 

Figure 769 is a sequential flow diagram representing the start of intra-cell 
20 diversity handover simultaneously with the access link setup. The procedure starts 

upon a call attempt to or from the mobile station 10 when it locates at the position 

illustrated at part (a) of Figure 768. 

In Figure 769, TACAFa designates a functional entity in the mobile station 10 

shown in part (a) of Figure 768. TACFa designates an anchor functional entity in the 
25 base station controller generated first after the mobile station 10 has started 

communication. TACFvl designates a functional entity in the base station controller 

in order that the base station controller controls the base station 21 where the mobile 

station 10 visits. BCFrl designates a functional entity in the base station 21 for 
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controlling radio resources. The subject method will be described with reference to 
part (a) of Figure 768 and Figure 769. 

As described above, each mobile station in the system always monitors the 
reception levels on perch channels corresponding to circumferential zones. Thus, 
5 although the mobile station 10 visits the radio zone 11 in part (a) of Figure 768, it 
monitors the reception level on the perch channel corresponding to the radio zone 12 
neighboring the zone 11. 

Assume that the reception level on the perch channel corresponding to the 
radio zone 12 is in excess of a threshold. In this case, the mobile station 10 notifies 
10 the network that the perch channel corresponding to the radio zone 12 is a candidate 
branch for realizing diversity handover. 

In addition, assume that the mobile station locates at the diversity handover 
zone 13, that the network is informed about a new candidate zone for diversity 
handover, and that the mobile station 10 originates a call attempt. In this case, when 
15 the base station controller 30 decides to establish diversity handover branches for the 
mobile station 10, the base station controller 30 generates an access link setup request 
and a diversity handover transition request for the mobile station 10 at the same time. 
According to the requests, the following steps are advanced in the system. 

(1) First, in order to establish an access link for the mobile station 10, the 
20 functional entity TACFa in the base station controller 30 sends a BEARER SETUP 
REQUEST INDICATION (ACCESS LINK SETUP request indication) to the functional 
entity TACFv in the base station controller 30 that controls the base station 21 where 
the mobile station 10 visits. The BEARER SETUP request indication includes 
information elements represented in Figures 404 and 433. 
25 (2) Upon the reception of the BEARER SETUP request indication, the functional 

entity TACFvl sends a message that includes contents of a BEARER-AND-RADIO- 
BEARER SETUP request indication and contents of an INTRA-BCFr HANDOVER 
BRANCH ADDITION request indication to the functional entity BCFr in base station 
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21. Contents of the BEARER-AND-RADIO-BEARER SETUP request indication are 
the same as those represented in Figure 407. The BEARER-AND-RADIO-BEARER 
SETUP request indication requests to setup the main branch constituted of the radio 
access link 41 between the base station 21 and the mobile station 10 and the wired 
5 access link 51 between the base station 21 and the base station controller 30. The 
INTRA-BCFr HANDOVER BRANCH ADDITION request indication requests to setup 
the auxiliary branch for intra-cell diversity handover. That is, it requests to setup the 
radio access link 42 represented in part (a) of Figure 768. Contents of the INTRA- 
BCFr HANDOVER BRANCH ADDITION request indication are the same as those 

10 represented in Figure 434. 

The message including the contents of the BEARER-AND-RADIO-BEARER 
SETUP request indication and the INTRA-BCFr HANDOVER BRANCH ADDITION 
request indication is the link setup message, which has been described at section 
2.5.3.6.2.1.3.2. Contents of the link setup message are represented in Figure 693, 

15 which has been referred for the description at section 2.5.3.6.2.1.3.2. As represented 
in Figure 693, the message includes an ACCH setup request information element for 
requesting the access link and an intra-BS DHO branch addition request information 
element indicating information on the auxiliary branch to be added for diversity 
handover. 

20 (3) Next, BCFr sends a message including contents of a RADIO BEARER SETUP 

PROCEEDING request indication and contents of an INTRA-BCFr HANDOVER 
BRANCH ADDITION response confirmation to TACFvl. The RADIO BEARER 
SETUP PROCEEDING request indication is a report indicating that the radio access 
link (41 in part (a) of Figure 768) is being established. Contents of the RADIO 

25 BEARER SETUP PROCEEDING request indication are the same as those represented 
in Figure 408. The INTRA-BCFr HANDOVER BRANCH ADDITION response 
confirmation is a report indicating that the setup of the radio access link 42 has been 
completed. Contents of the INTRA-BCFr HANDOVER BRANCH ADDITION 



F0220/2551 



332 

response confirmation are the same as those represented in Figure 435. 

(4) Upon the reception of the RADIO BEARER SETUP PROCEEDING request 
indication and the INTRA-BCFr HANDOVER BRANCH ADDITION response 
confirmation from BCFrl, TACFvl sends a RADIO BEARER SETUP REQUEST 
request indication to TACFa to request the mobile station 10 to establish the radio 
access links 41 and 42. The RADIO BEARER SETUP REQUEST request indication 
includes information elements represented in Figures 409 and 436. 

(5) Then, TACFa in the base station controller 30 sends a message including 
contents of a HANDOVER BRANCH ADDITION request indication and contents of a 
RADIO BEARER SETUP request indication to TACAF of the mobile station 10. The 
message requests to establish the radio access link 41, which belongs to the main 
branch which will be the subject of synchronization later, and the radio access link 42, 
which is the auxiliary link for diversity handover. The message is the radio bearer 
setup message, which has been described at section 2.5.2.4.2.3.4.1. Contents of the 
radio bearer setup message are represented in Figure 624, which has been referred for 
the description at section 2.5.2.4.2.3.4.1. As represented in Figure 624, the message 
includes information on the main branch and a DHO branch addition information 
indicating information on the auxiliary branch to be added for diversity handover. 

(6) Subsequently, TACAFa in the mobile station 10 starts to. synchronize process 
of the TACAFa with process of BCFrl in the base station with respect to the radio 
access link of the main branch. 

(7) After completion of the synchronization, BCFrl in the base station 21 sends a 
BEARER-AND-RADIO-BEARER SETUP response confirmation to TACFvl in the 
base station controller 30 to report the completion of the synchronization on the radio 
access link. Figure 413 represents the contents of the BEARER-AND-RADIO- 
BEARER SETUP response confirmation. 

(8) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 
confirmation, TACFvl sends a BEARER SETUP response confirmation to TACFa in 
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order to report the completion of the access link setup. Figure 414 represents the 
contents of the BEARER SETUP response confirmation. 

Consequently, the access link setup is established and the system state is 
transited to diversity handover. 



Figure 770 is a sequential flow diagram representing the start of inter-cell 
diversity handover simultaneously with the access link setup. The procedure starts 
upon a call attempt to or from the mobile station 10 when it locates at the position 
illustrated at part (b) of Figure 768. 

In Figure 770, TACAFa designates a functional entity in the mobile station 10 
shown in part (b) of Figure 768. TACFa designates a functional entity in the base 
station controller generated first after the mobile station 10 has started 
communication. TACFvl and TACFv2 designate functional entities in the base 
station controller in order that the base station controller controls the base stations 21 
and 22 where the mobile station 10 visits. BCFrl and BCFr2 designate functional 
entities in the base stations 21 and 22 for controlling radio resources. The subject 
method will be described with reference to part (b) of Figure 768 and Figure 769. 

As represented in part (b) of Figure 768, assume that when the mobile station 
10 moves into the diversity handover zone 13, the mobile station 10 originates a call 
attempt. In this case, the base station controller 30 generates an access link setup 
request and a diversity handover transition request for the mobile station 10 at the 
same time. According to the requests, the following steps are advanced in the system. 

(1) First, in order to establish an access link for the mobile station 10, TACFa in 
the base station controller 30 sends a BEARER SETUP request indication (ACCESS 
LINK SETUP request indication) to TACFvl in the base station controller 30. The 
contents of the BEARER SETUP request indication are represented in Figure 404. 
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(2) Upon the reception of the BEARER SETUP request indication, TACFvl sends 
a BEARER-AND-RADIO-BEARER SETUP request indication to request to establish 
the radio access link 41 between the base station 21 and the mobile station 10 and to 
establish the wired access link between the base station 21 and the base station 
controller 30. Contents of the BEARER-AND-RADIO-BEARER SETUP request 
indication are represented in Figure 407. 

(3) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP request 
indication, BCFrl starts to establish the radio access link and the wired access link 
and sends a RADIO BEARER SETUP PROCEEDING request indication to TACFvl to 
report that the radio access link. Contents of the RADIO BEARER SETUP 
PROCEEDING request indication are represented in Figure 404. 

(4) Upon the reception of the RADIO BEARER SETUP PROCEEDING request 
indication, TACFvl in the base station controller 30 sends a RADIO BEARER SETUP 
REQUEST request indication to TACFa to request the mobile station 10 to establish 
the radio access link 41 while the base station 21 establishes the radio access link 41. 
The RADIO BEARER SETUP REQUEST request indication includes information 
elements represented in Figures 409. 

(5) Next, TACFa in the base station controller 30 sends a BEARER SETUP 
request indication (ACCESS LINK SETUP request indication) to the functional entity 
TACFv2 in the base station controller 30 that controls the base station 22 where the 
mobile station 10 visits. The BEARER SETUP request indication includes 
information elements represented in Figure 442. 

(6) Upon the reception of the BEARER SETUP request indication, TACFv2 sends 
a BEARER-AND-RADIO-BEARER SETUP request indication to request to establish 
the radio access link 44 between the base station 22 and the mobile station 10 and to 
establish the wired access link between the base station 22 and the base station 
controller 30. Contents of the BEARER-AND-RADIO-BEARER SETUP request 
indication are represented in Figure 445. 
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(7) After completion of the setup of the radio access link and the wired access link, 
BCFr2 in the base station 22 sends a BEARER-AND-RADIO-BEARER SETUP 
response confirmation represented in Figure 446 to TACFv2 in the base station 
controller 30 to notify of the completion. 
5 (8) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 

confirmation, TACFv2 sends a RADIO BEARER SETUP REQUEST request indication 
represented in Figure 447 to TACFa in order to request the mobile station 10 to 
establish the radio access link 44. 

q (9) Upon the reception of the RADIO BEARER SETUP REQUEST request 

10 indication, TACFa sends a message including contents of a HANDOVER BRANCH 

p s ADDITION request indication and contents of a RADIO BEARER SETUP request 

indication to TACAF of the mobile station 10. The message requests to establish the 

^ radio access link 41, which belongs to the main branch which will be the subject of 

C3 synchronization later, and the radio access link 44, which is the auxiliary link for 

ffj 15 diversity handover. 

?5 (10) Subsequently, the mobile station 10 starts to synchronize process of the mobile 

" station with process of the base station 21 with respect to the radio access link 41 of 

the main branch. 

(11) After completion of the synchronization, BCFrl in the base station 21 sends a 
20 BEARER-AND-RADIO-BEARER SETUP response confirmation to TACFvl in the 

base station controller 30 to report the completion of the synchronization on the radio 
access link. Figure 413 represents the contents of the BEARER-AND-RADIO- 
BEARER SETUP response confirmation. 

(12) Then, TACFvl sends a BEARER SETUP response confirmation (ACCESS 
25 LINK SETUP response confirmation) to TACFa in order to report the completion of the 

access link setup. Figure 414 represents the contents of the BEARER SETUP 
response confirmation. 

Consequently, the access link setup is established and the system state is 
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transited to diversity handover. 

3.3.3 OPERATIONS OF MOBILE STATION AND BASE STATION FOR 

THE CONTROL METHOD 
5 3.3.3.1 OPERATION OF MOBILE STATION 

Figure 786 represents in detail the operation in Figure 770. More specifically, 
it particularly represents the operation after the transmission of the message 
including the contents of the HANDOVER BRANCH ADDITION request indication 
and of the RADIO BEARER SETUP request indication from TACFa of the base station 

10 controller to TACAF of the mobile station. 

As represented in Figure 786, upon the reception of the HANDOVER 
BRANCH ADDITION request indication and the RADIO BEARER SETUP request 
indication, TACAFa establishes the main branch. More specifically, the mobile 
station allots physical resources (frequency and codes) for radio communication to a 

15 radio transceiver device of the mobile station, and then, synchronize process of the 
mobile station with process of BCFrl of the base station with respect to upward 
(reverse) communication and downward (forward) communication. After completion 
of the synchronization, voice or data communication is started. 

Immediately after the completion of setup of the main branch in the above- 

20 described fashion, the mobile station sets up the auxiliary branch. In this case, the 
mobile station allots physical resources for the auxiliary branch. Immediately 
afterward, the mobile station starts to receive signals through the auxiliary branch, 
thereby commencing diversity combining by virtue of the main and auxiliary branches 
without synchronization unlike the main branch setup. 

25 Figure 787 is a flowchart of an operation of the mobile station, which is 

appropriate to realizing the above-mentioned operation. More specifically, this 
flowchart represents an operation for processing in the mobile station after receiving a 
message including both of the setup request of the main branch and the additional 
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setup request of the auxiliary branch from the base station controller when any access 
link is not established. 

As represented in the flowchart, upon the reception of a signal at step SI, the 
mobile station transits from the signal reception standby state to step S2. At step S2, 
5 the mobile station determines whether or not the received signal contains information 
on the main branch. If the determination is affirmative, the mobile station 
establishes the main branch at step S3 in accordance with the main branch 
information. 

Q Next, the mobile station determines whether or not the received signal 

10 contains information on the auxiliary branch at step S4. If the determination is 
i"j affirmative, the mobile station establishes the auxiliary branch at step S5 in 

ril accordance with the auxiliary branch information. As represented by the circulation 

through steps S4 and S5, if a plurality of auxiliary branches are indicated by the 
\f_ received signal, the mobile station establishes all of the auxiliary branches in 

fU 15 accordance with the information. 

Q If there is not a next indication of auxiliary branch in the received signal, the 

determination at step S4 should be negative, so that the mobile station returns to the 
signal reception standby state. 

As will be understood from the above description, if the mobile station receives 
20 a message including both of the setup request of the main branch and the additional 
setup request(s) of the auxiliary branch (es), it establishes all of the branches informed 
by the message. This operation contributes the operation represented in Figure 786 
for starting diversity handover simultaneously with the access link setup. Although 
the above -description with reference to Figures 786 and 787 relates to inter-cell 
25 diversity handover with the access link setup, similar operations can be applied to 
intra-cell diversity handover with the access link setup. 

For easy comparison, Figure 788 represents a conventional operation of a 
mobile station after the access link setup while Figure 789 represents a conventional 
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flowchart of an operation for realizing the access link setup. As represented in Figure 
788, according to the prior art, a RADIO BEARER SETUP request indication is sent 
from the base station controller to the mobile station in order to establish the first 
access link, and then, a HANDOVER BRANCH ADDITION request indication is sent 
5 from the base station controller to the mobile station in order to start diversity 
handover. In other words, an extra message transmission from the base station 
controller to the mobile station is necessary in comparison with the invented system. 

Furthermore, since the RADIO BEARER SETUP request indication and the 
O HANDOVER BRANCH ADDITION request indication are sent to the mobile station at 

B p 10 different times according to the prior art, the mobile station treats received signals 

uj according to the flowchart represented in Figure 789. As represented in the flowchart, 

i\l upon the reception of a signal at step Sll, the mobile station transits from the signal 

r ~ reception standby state to step S12. As depicted by steps S12 and S13, if the signal 

contains information on the main branch, the mobile station establishes the main 
r« 15 branch in accordance with the main branch information. On the other hand, if the 

C3' signal contains information on the auxiliary branch, the mobile station establishes the 

auxiliary branch in accordance with the auxiliary branch information as depicted by 
steps S 12 and S 14. 

Unlikely, according to the invented system, one message including 
20 information on all of the main branch and auxiliary branch(es) is sent to the mobile 
station, so that the mobile station establishes all branches. Therefore, the number of 
signal transmission between the network and the mobile station can be reduced, so 
that the transition to diversity handover can be achieved efficiently. 



25 3.3.3.2. OPERATION OF BASE STATION 

As already described with reference to Figures 769, in order to transit intra-cell 
diversity handover simultaneously with the access link setup, the message including 
the contents of the BEARER-AND-RADIO BEARER SETUP request indication and 
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INTRA-BCFr HANDOVER BRANCH ADDITION request indication is sent to the 
base station in the system. The base station in the system reads the information on 
all of the branches contained in the message and establishes all branches in 
accordance with the branch information. If this operation is represented as in a 
flowchart, it is the same as Figure 787. Therefore, the illustration of flowchart and 
the description thereof are omitted. 

3.4 DIVERSITY HANDOVER BRANCH ADDITION 

SIMULTANEOUSLY WITH BRANCH REPLACEMENT 
3.4. 1 BACKGROUND OF INVENTION OF THE PROCEDURE 

When a mobile station moves from a radio zone to a neighboring radio zone 
where the available frequency band is different from that of the former zone, branch 
replacement is carried out. Branch replacement is also carried out to replace the 
frequency band used by the mobile station with another frequency band if 
communication quality is deteriorated although the mobile station does not move. 

In accordance with prior art, transition to diversity handover is often 
necessary immediately after the completion of branch replacement. Figure 771 
represents one of the situations where it is necessary. As represented in Figure 771, 
while frequency band fl is used in cell 1, frequency band f2 is used in cell 2. Assume 
that a mobile station moves along the direction indicated by the arrow into the zone 
where cells 1, 2, and 3 overlap one another. In this case, when the mobile station 
quits cell 1, branch replacement is carried out at the diversity handover zone where 
cells 2 and 3 overlap each other. 

In accordance with prior art, first, the branch corresponding to cell 1 used by 
the mobile station is replaced with the branch corresponding to cells 2 and 3, and then, 
another branch corresponding to cell 3 is added for enabling diversity handover. 

However, the branch replacement needs a series of information flows 
transported between the mobile station and the network as illustrated in Figure 772. 
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In addition, in order to transit to diversity handover, needed is a series of information 
flows transported between the mobile station and the network as illustrated in Figure 
767. The information flows shown in Figures 772 and 767 have been already 
described and will be described for explanation of the invented control method. Thus, 
the description is omitted here. 

According to the above circumstances, a large number of control signals are 
transported between the mobile station and the network and within the network for 
the branch replacement and the diversity handover in progression. Consequently, the 
system should endure its enormous control burden. 

In addition, since the mobile station can use only a single radio access link 
directly after the branch replacement, the transmission power for this access link is 
strong so as to enlarge interference levels at other radio access links. Therefore, the 
capacity or the number of channels at the cell may be decreased. 

The above-mentioned problems occur at the situation where the transition to 
inter-cell diversity handover is possible after the branch replacement as represented in 
Figure 771. The same problems occur at the situation where the transition to intra- 
cell diversity handover is possible after the branch replacement. The control method 
described below will resolve the above-mentioned problems. 

3.4.2 DIVERSITY HANDOVER BRANCH ADDITION 

SIMULTANEOUSLY WITH BRANCH REPLACEMENT OF 
EMBODIMENT 

According to the embodiment of the system, when it is possible transit to 
diversity handover at the occurrence of the initiation to branch replacement, the 
branch structure before the initiation is immediately replaced with the branch 
structure necessary for diversity handover. Figure 773 is a sequential flow diagram 
representing an operation in the invented system which is carried out when the mobile 
station moves from cell 1 to the diversity handover zone where cells 2 and 3 overlap 
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each other (see Figure 771). 

In Figure 773, TACAFa designates a functional entity in the mobile station 
shown in Figure 771. TACFa designates a functional entity in the base station 
controller generated first after the mobile station has started communication. 
5 TACFvl, TACFv2, and TACFv3 designate functional entities in the base station 
controller in order that the base station controller controls base stations where the 
mobile station 10 visits. In the example in Figure 771, TACFvl, TACFv2, and 
TACFv3 correspond to cells 1, 2, and 3, respectively. BCFrl, BCFr2, and BCFr3 
designate functional entities in the base stations for controlling radio resources. In 
10 the example in Figure 771, BCFrl, BCFr2, and BCFr3 correspond to cells 1, 2, and 3, 
respectively. The subject method will be described with reference to Figures 771 and 
773. 

In Figure 771, assume that when the mobile station enters the diversity 
handover zone where cells 1, 2, and 3 overlap one another, the mobile station notifies 

15 the network that the cells 2 and 3 are candidate cells for realizing diversity handover 
and the network recognizes that cells 2 and 3 are candidate cells. In addition, assume 
that the mobile station exits cell 1 and moves into the diversity handover zone where 
cells 2 and 3 overlap each other. In this case, the base station controller generates a 
branch replacement request and a diversity handover transition request for the mobile 

20 station at the same time. According to the requests, the following steps are advanced 
in the system. 

(1) TACAFa in the base station controller sends a BEARER SETUP request 
indication to TACFv2 in the base station controller in order to establish a branch 
between the base station controller and the mobile station through the base station in 

25 charge of cell 2. 

(2) Upon the reception of the BEARER SETUP request indication, TACFv2 sends 
a BEARER-AND-RADIO-BEARER SETUP request indication to BCFr2 in the base 
station in charge of cell 2. The BEARER-AND-RADIO-BEARER SETUP request 
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indication requests to establish a radio access link between the base station in charge 
of cell 2 and the mobile station and a wired access link between the base station and 
the base station controller. 

(3) After starting the establishment of the radio and wired access links upon the 
reception of the BEARER-AND-RADIO-BEARER SETUP request indication, BCFr2 of 
the base station for cell 2 sends a RADIO BEARER SETUP PROCEEDING request 
indication to TACFv2 in the base station controller to report that the access link setup 
is proceeding. 

(4) Upon the reception of the RADIO BEARER SETUP PROCEEDING request 
indication, TACFv2 sends a RADIO BEARER SETUP REQUEST request indication to 
TACFa to request the mobile station to establish the radio access link between the 
mobile station and the base station for cell 2. 

(5) Upon the reception of the RADIO BEARER SETUP REQUEST request 
indication, TACFa sends another BEARER SETUP request indication to TACFv3 to 
request to establish another branch between the base station controller and the mobile 
station through the base station in charge of cell 3. 

(6) Upon the reception of the BEARER SETUP request indication, TACFv3 sends 
another BEARER-AND-RADIO-BEARER SETUP request indication to BCFr3 in the 
base station in charge of cell 3. The BEARER-AND-RADIO-BEARER SETUP request 
indication requests to establish a radio access link between the base station in charge 
of cell 3 and the mobile station and a wired access link between the base station and 
the base station controller. 

(7) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP request 
indication, BCFr3 of the base station for cell 3 starts the establishment of the radio 
and wired access links, and then, sends another RADIO BEARER SETUP 
PROCEEDING request indication to TACFv3 in the base station controller to report 
that the access link setup is proceeding. 

(8) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 
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confirmation, TACFv3 sends a RADIO BEARER SETUP REQUEST request indication 
to TACFa to request the mobile station to establish the radio access link between the 
mobile station and the base stations for cells 2 and 3. 

(9) Upon the reception of the RADIO BEARER SETUP REQUEST request 
5 indication, TACFa sends a message including contents of a NON-SOFT HANDOVER 
EXECUTION request indication and of a HANDOVER BRANCH ADDITION request 
indication to TACAfa in the mobile station. The NON-SOFT HANDOVER 
EXECUTION request indication requests the replacement of main branch while the 
HANDOVER BRANCH ADDITION request indication requests to add an auxiliary 

10 branch. With such constituents, the message requests the mobile station to replace a 
former branch corresponding to cell 1 where frequency fl is used with a new branch 
corresponding to cell 2 where frequency f2 is used, and requests the mobile station to 
add an auxiliary branch corresponding to cell 3 where frequency £2 is used. The 
message is the handover command message, which has been described at section 

15 2.5.2.4.2.3.4.4. Contents of the message are represented in Figure 627, which has 
been referred for the description at section 2.5.2.4.2.3.4.4. As represented in Figure 
627, the message includes a branch replacement information element indicating 
information on the new main branch and a DHO branch addition information element 
indicating information on the auxiliary branch to be added for diversity handover. 

20 (10) Subsequently, the mobile station starts to synchronize process of the mobile 

station with process of the base station for cell 2 with respect to the main branch. 

(11) After completion of the synchronization, BCFr2 in the base station for cell 2 
sends a BEARER-AND-RADIO-BEARER SETUP response confirmation to TACFv2 in 
the base station controller to report the completion of the synchronization on the radio 

25 access link. 

(12) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 
confirmation, TACFv2 sends a BEARER SETUP response confirmation to TACFa in 
order* to report the completion of the access link setup. 
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(13) Upon the reception of the BEARER SETUP response confirmation, TACFa in 
the base station controller sends a BEARER RELEASE request indication to TACFvl 
to request to release the access link formerly used by the base station for cell 1 for 
communicating with the mobile station. 

(14) Upon the reception of the BEARER RELEASE request indication, TACFvl 
sends a BEARER-AND-RADIO-BEARER RELEASE request indication to BCFrl in 
the base station for cell 1 to request to release the radio access link and wired access 
link formerly used by the base station for cell 1 for communicating with the mobile 
station. 

(15) Upon the reception of the BEARER -AND-RADIO-BEARER RELEASE 
request indication, BCFrl in the base station for cell 1 releases the radio access link 
and wired access link formerly used by the base station for cell 1 for communicating 
with the mobile station, and sends a BEARER-AND-RADIO-BEARER RELEASE 
response confirmation to TACFvl to report the completion of access link release. 

(16) Upon the reception of the BEARER-AND-RADIO-BEARER RELEASE 
response confirmation, TACFvl in the base station sends a BEARER RELEASE 
response confirmation to TACFa to report the completion of access link release. 

Therefore, the mobile station can transit to diversity handover using branches 
corresponding to cells 2 and 3. 

An operation of the system when the mobile station can carries out inter-cell 
diversity handover directly after the branch replacement has been described with 
reference to Figures 771 and 773. A similar operation is executed for the case when 
the mobile station can carries out intra-cell diversity handover directly after the 
branch replacement. In this case, the base station controller sends a single message 
including information instructing the branch replacement and information instructing 
the diversity handover branch addition to the single base station in charge of intra cell 
diversity handover. 
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3.4.3 OPERATIONS OF MOBILE STATION AND BASE STATION FOR 

THE CONTROL METHOD 

3.4.3.1 OPERATION OF MOBILE STATION 

As described above, a message including an instruction on the branch 
replacement and an instruction on the addition of auxiliary branch for diversity 
handover is sent to the mobile station in the system. Therefore, when the mobile 
station receives this kind of message from the network, the mobile station carries out 
the branch replacement and the addition of auxiliary branch for diversity handover. 
In this case, the same operation as described in section 3.3.3.1 is carried out. 

3.4.3.2 OPERATION OF BASE STATION 

As described above, a message including an instruction on the branch 
replacement and an instruction on the addition of auxiliary branch for intra-cell 
diversity handover is sent to the base station in the system. Therefore, when the base 
station receives this kind of message from the network, the base station carries out the 
branch replacement and the addition of auxiliary branch for diversity handover. 

3.5 FIRST METHOD FOR CONTROLLING BRANCH STRUCTURE 

AND FREQUENCY BAND WHEN A NEW CALL OCCURS WHILE 
MOBILE STATION CAPABLE OF TREATING A PLURALITY OF 
CALLS SIMULTANEOUSLY TREATS AN EXISTENT CALL 
3.5.1 BACKGROUND OF INVENTION OF THE METHOD 

There is provided a mobile station capable of treating a plurality of calls 
simultaneously. In accordance with prior art, this kind of mobile station is not 
provided with means for equalizing branch structure and frequency band as to all calls. 
Different branch structures and different frequency bands are sometimes allocated to 
calls while the mobile station treats them. Thus, it is necessary for the network to 
control respective calls with regard to handover of mobile station and transmission 
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power, so that the network should endure an enormous burden with respect to 
preparation of overheads of messages. The control method described below will 
resolve the above-mentioned problems. 



As represented in part (a) of Figure 774, BTSl and BTS2 have radio zones, 
respectively, where frequency fl is used. The MS treating call 1 communicates with 
BTSl and BTS2 such that diversity reception from BTSl and BTS2 is carried put at 
the diversity handover transition state. In this state, assume that a new call attempt 
occurs to or from the MS. 

In this case, the branch structure and the frequency band used for the new call 
(call 2 in Figure 774) are controlled to be equalized with those used for the existent call 
(call 1 in Figure 774) in the system. More specifically, a frequency band fl has been 
used for existent call 1 and branches corresponding to BTSl and BTS2 have been used 
for call 1 as represented in part (a) of Figure 774. Therefore, upon the occurrence of 
new call 2, the frequency band fl is also used and branches corresponding to BTSl and 
BTS2 are also used for call 2 in part (b) of Figure 774. 

Figure 775 is a sequential flow diagram representing the operation 
exemplified in Figure 774 of the system. In Figure 775, TACAFa designates a 
functional entity in the MS shown in Figure 774. TACFa designates a functional 
entity in the base station controller generated first after the MS has started 
communication. TACFvl and TACFv2 designate functional entities in the base 
station controller in order that the base station controller controls BTSl and BTS2 
where the MS visits. BCFrl and BCFr2 designate functional entities in BTSl and 
BTS2, respectively, for controlling radio resources. The subject method will be 
described with reference to Figures 774 and 775. 

If new call 2 occurs to or from the MS while the MS treats existent call 1 such 
that diversity reception from BTSl and BTS2 is carried out at the diversity handover 
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transition state as represented in part (a) of Figure 774, TACFa in the base station 
controller receives a request for establishing a new access link corresponding to new 
call 2 and a request for equalizing the branch structure for call 2 with that for call 1. 
According to the requests, the following steps are advanced in the system. 
5 (1) In order to request to establish an access link for new call 2 via BTS1 where 

the MS visits, TACFa sends a BEARER SETUP request indication to TACFvl in the 
base station controller, which controls BTS1. 

(2) Upon the reception of the BEARER SETUP request indication, TACFvl sends 
a BEARER- AND -RADIO-BEARER SETUP request indication to BCFrl in BTSl to 

10 request to establish a radio access link between BTSl and the MS and a wired access 
link between BTSl and the base station controller for new call 2. 

(3) Upon the reception of the BEARER-AND-RADIOBEARER SETUP request 
indication, BCFrl in BTSl starts establishing the requested radio and wired access 
links, and then, sends a RADIO BEARER SETUP PROCEEDING request indication to 

15 TACFvl in the base station controller to report that the access link setup is 
proceeding. 

(4) Upon the reception of the RADIO BEARER SETUP PROCEEDING request 
indication, TACFvl sends a RADIO BEARER SETUP REQUEST request indication to 
TACFa to request to establish the radio access link between the MS and BTSl. 

20 (5) On the other hand, in order to request to establish an access link for new call 2 

via BTS2, TACFa sends another BEARER SETUP request indication to TACFv2 in the 
base station controller, which controls BTS2. 

(6) Upon the reception of the BEARER SETUP request indication, TACFv2 sends 
a BEARER- AND-RADIO-BEARER SETUP request indication to BCFr2 in BTS2 to 

25 request to establish another radio access link between BTS2 and the MS and another 
wired access link between BTS2 and the base station controller. 

(7) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP request 
indication, BCFr2 in BTS2 establishes the requested radio and wired access links, and 
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then, sends a BE ARER- AND -R ADI O -BE ARER SETUP response confirmation to 
TACFv2 in the base station controller to report that the access link setup is completed. 

(8) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 
confirmation, TACFv2 sends a RADIO BEARER SETUP REQUEST request indication 
to TACFa to request to establish the radio access link between the MS and BTS2. 

(9) By this stage, TACFa has received two RADIO BEARER SETUP REQUEST 
request indications: the first is sent from TACFvl to request the establishment of the 
radio access link between the MS and BTSl, and the second is sent from TACFv2 to 
request the establishment of the radio access link between the MS and BTS2. Upon 
the reception of the second RADIO BEARER SETUP REQUEST request indication 
from TAGFv2, TACFa sends a single message including contents of a HANDOVER 
BRANCH ADDITION request indication and of a RADIO BEARER SETUP request 
indication to TACAFa in the MS. The RADIO BEARER SETUP request indication is 
used for requesting to establish the main branch, which will be the subject of 
synchronization later, via BTS1. The HANDOVER BRANCH ADDITION request 
indication is used for establishing the auxiliary branch via BTS2 for diversity 
handover. Thus, the message requests the MS to establish the radio access link of the 
main branch via BTS1 and the radio access link of the auxiliary branch via BTS2 for 
new call 2. 

(10) Subsequently, the MS starts to synchronize process of the MS with process of 
the BTS1 with respect to the radio access link of the main branch. 

(11) After completion of the synchronization, BCFrl in BTSl sends a BEARER- 
AND-RADIO-BEARER SETUP response confirmation to TACFvl in the base station 
controller to report the completion of the synchronization on the radio access link. 

(12) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 
confirmation, TACFvl sends a BEARER SETUP response confirmation to TACFa in 
order to report the completion of the access link setup. Consequently, the MS can use 
the same diversity handover branches via BTSl and BTS2 and can use the same 
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frequency fl for both calls 1 and 2. 



3.6 



SECOND METHOD FOR CONTROLLING BRANCH STRUCTURE 



AND FREQUENCY BAND WHEN ANEW CALL OCCURS WHILE 



MOBILE STATION CAPABLE OF TREATING A PLURALITY OF 



CALLS SIMULTANEOUSLY TREATS AN EXISTENT CALL 



3.6.1 



BACKGROUND OF INVENTION OF THE METHOD 



In the above control method described at section 3.5, the branch structure and 
the frequency band for the new call are equalized with those for the existent call when 
the new call attempt occurs during communication by the mobile station. 

However, if traffic at at least one of the branches or at the frequency used for 
the existent call is congested or another inconvenient situation happen at the 
occurrence of the new call attempt, it is impossible to allocate the same branch 
structure or the frequency band to the new call. In this case, the call attempt cannot 
be accepted. The control methods described below will resolve the above-mentioned 
problems. 

3.6.2 EMBODYING METHODS 

The control methods according to embodiments of the invention is carried out 
when a new call occurs while the mobile station capable of treating a plurality of calls 
simultaneously treats an existent call and when it is impossible to assign the same 
branch structure or the same frequency band as for the existent call to the new call by 
insufficient capacity or another reason. In accordance with the embodiments, at the 
establishment of the new call, another branch structure or another communication 
frequency band which can continue both of the existent and new calls is selected, and 
the selected branch structure or communication frequency band is assigned to both of 
the existent and new calls. 

Figure 776 represents one of the methods according to the embodiments. In 
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part (a) of Figure 776, an MS uses a branch at frequency fl between BTS1 and the MS, 
thereby treating call 1. Then, an attempt of new call 2 occurs from the MS. However, 
assume that the capacity of BTSl is insufficient for the needs of new call 2. 

However, the capacity of BTS2 adjacent to BTSl is sufficient for the needs of 
calls 1 and 2. In addition, BTS2 uses the same frequency band fl as of BTSl. If a 
diversity branch structure including branches via BTSl and BTS2 is used for call 1, 
the transmission power for each branch may be reduced and the capacity of BTSl can 
be enhanced to afford call 2 newly. 

Accordingly, in the embodying method, the former branch structure for call 1 
is replaced with the diversity branch structure including branches via BTSl and BTS2 
at the establishment of call 2 as represented in part (b) of Figure 776. The same 
branch structure and the same frequency band are allocated to new call 2. 

Figure 777 represents another method according to another embodiment. In 
part (a) of Figure 777, an MS'uses a branch at frequency fl between BTSl and the MS, 
thereby treating call 1. Then, an attempt of new call 2 occurs from the MS. However, 
assume that the capacity of BTSl is insufficient for the needs of new call 2. 

However, the capacity of BTS2 adjacent to BTSl is sufficient for the needs of 
calls 1 and 2. However, BTS2 uses a frequency band f2, which is different from that of 
BTSl, so that the MS cannot conduct diversity reception by BTSl and BTS2. 

Accordingly in the embodying method, the former branch structure for call 1 
is replaced with another branch structure constituted of only the single branch via 
BTS2 at the establishment of call 2 as represented in part (b) of Figure 777. The 
same branch structure and the same frequency band are allocated to new call 2. 

Figure 778 is a sequential flow diagram representing the operation 
exemplified in Figure 776 of the system. In Figure 778, TACAFa designates a 
functional entity in the MS shown in Figure 776. TACFa designates a functional 
entity in the base station controller generated first after the MS has started 
communication. TACFvl-2 designates an instance of a functional entity in the base 
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station controller in order that the^base station controller controls BTS1 where the MS 
visits. TACFvl-2 corresponds to call 1. TACFv2-l and TACFv2-2 designate 
instances of functional entities in the base station controller in order that the base 
station controller controls BTS2 where the MS visits. TACFv2-l and TACFy2-2 
correspond to calls 1 and 2, respectively. BCFrl-2 designates an instance of a 
functional entity in BTSl for controlling radio resources. BCFrl-2 corresponds to call 
1. BCFr2-l and BCFr2-2 designate instances of functional entities in BTS2 for 
controlling radio resources. BCFr2-l and BCFr2-2 correspond to calls 1 and 2, 
respectively. The subject method will be described with reference to Figures 776 and 
778. 

If new call 2 occurs to or from the MS while the MS treats existent call 1 using 
BTSl as represented in part (a) of Figure 776, TACFa in the base station controller 
ascertains radio resources occupied by existent call 1 and all available radio resources 
in all of the base stations (BTSl and BTS2 in Figure 776) where the MS visits. 

Then, TACFa determines how to treat all calls, including the new call, for the 
MS on the basis of the ascertainment. In other words, TACFa in the base station 
controller determines to allocate the branch structure constituted of the branch 
between the MS and BTSl and the branch between the MS and BTS2 to calls 1 and 2 
as described above with reference to part (b) of Figure 776. According to the 
determination, the following steps are advanced in the system. 

(1) In order to request to establish an access link for new call 2 via BTSl where 
the MS visits, TACFa sends a BEARER SETUP request indication to TACFvl-2 in the 
base station controller, which controls BTSl. 

(2) Upon the reception of the BEARER SETUP request indication, TACFvl-2 
sends a BEARER-AND-RADIO-BEARER SETUP request indication to BCFrl-2 in 
BTSl to request to establish a radio access link between BTSl and the MS and a wired 
access link between BTSl and the base station controller for call 2. 

(3) Additionally, TACFa in the base station controller sends another BEARER 
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SETUP request indication to TACFv2-l in the base station controller, which controls 
BTS2 in order to request to establish an access link for existent call 1 via BTS2 where 
the MS visits. 

(4) Upon the reception of the BEARER SETUP request indication, TACFv2-l 
sends another BEARER-AND-RADIO-BEARER SETUP request indication to BCFr2- 
1 in BTS2 to request to establish another radio access link between BTS2 and the MS 
and another wired access link between BTS2 and the base station controller for call 1. 

(5) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP request 
indication from TACFvl-2, BCFrl-2 in BTS1 starts establishing the requested radio 
and wired access links, and then, sends a RADIO BEARER SETUP PROCEEDING 
request indication to TACFvl-2 in the base station controller to report that the access 
link setup is proceeding. 

(6) Upon the reception of the RADIO BEARER SETUP PROCEEDING request 
indication, TACFvl-2 sends a RADIO BEARER SETUP REQUEST request indication 
to TACFa to request to establish the radio access link for new call 2 between the MS 
andBTSl. 

(7) On the other hand, upon the reception of the BEARER-AND-RADIO-BEARER 
SETUP request indication from TACFv2-l, BCFr2-l in BTS2 starts establishing the 
requested radio and wired access links, and then, sends a BEARER-AND-RADIO- 
BEARER SETUP PROCEEDING request indication to TACFv2-l in the base station 
controller to report that the access link setup is proceeding. 

(8) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP 
PROCEEDING request indication, TACFv2-l sends a RADIO BEARER SETUP 
REQUEST request indication to TACFa to request to establish the radio access link for 
existent call 1 between the MS and BTS2. 

(9) In addition, TACFa in the base station controller sends another BEARER 
SETUP request indication to TACFv2-2 in the base station controller, which controls 
BTS2 in order to request to establish an access link for new call 2 via BTS2 where the 
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MS visits. 

(10) Upon the reception of the BEARER SETUP request indication, TACFv2-2 
sends another BEARER-AND -RADIO-BEARER SETUP request indication to BCFr2- 
2 in BTS2 to request to establish another radio access link between BTS2 and the MS 

5 and another wired access link between BTS2 and the base station controller for new 
call 2. 

(11) Upon the reception of the BEARER -AND-RADIO-BEARER SETUP request 
indication, BCFr2-2 in BTS2 starts establishing the requested radio and wired access 
links, and then, sends another BEARER-AND-RADIO BEARER SETUP 

10 PROCEEDING request indication to TACFv2-2 in the base station controller to report 
that the access link setup is proceeding. 

.(12) Upon the reception of the BEARER-AND-RADIO -BEARER SETUP response 
confirmation, TACFv2-2 sends a RADIO BEARER SETUP REQUEST request 
indication to TACFa to request to establish the radio access link for call 2 between the 

15 MS and BTS2. 

(13) By this stage, TACFa has received three RADIO BEARER SETUP REQUEST 
request indications: the first is sent from TACFvl-2 to request the establishment of the 
radio access link between the MS and BTSl for new call 2, the second is sent from 
TACFv2-l to request the radio access link between the MS and BTS2 for existent call 1, 

20 and the third is from TACFv2-2 for the radio access link between the MS and BTS2 for 
new call 2. Upon the reception of the third RADIO BEARER SETUP REQUEST 
request indication from TACFv2-2, TACFa sends a single message including contents 
of a HANDOVER BRANCH ADDITION request indication and of a RADIO BEARER 
SETUP request indication to TACAFa in the MS. The RADIO BEARER SETUP 

25 request indication is used for requesting to establish the main branch for call 2, which 
will be the subject of synchronization later, via BTSl. The HANDOVER BRANCH 
ADDITION request indication is used for establishing the auxiliary branches via BTS2 
for diversity handover of both calls 1 and 2. 
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(14) Subsequently, the MS starts to synchronize process of the MS with process of 
the BTS1 with respect to the radio access link of the main branch for new call 2. 

(15) After completion of the synchronization, BCFrl-2 in BTS1 sends a BEARER- 
AND-RADIO-BEARER SETUP response confirmation to TACFvl-2 in the base station 
controller to report the completion of the synchronization on the radio access link. 

(16) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 
confirmation, TACFvl-2 in BTS1 sends a BEARER SETUP response confirmation to 
TACFa in order to report the completion of the access link setup. Consequently, the 
MS can use the same diversity handover branches via BTS1 and BTS2 and can use the 
same frequency fl for both calls 1 and 2. 

Figure 779 is a sequential flow diagram representing the operation 
exemplified in Figure 777 of the system. In Figure 779, meanings of TACAFa, 
TACFvl-1, and so on are the same as those in Figure 778. Another method will be 
described with reference to Figures 777 and 779. 

If new call 2 occurs to or from the MS while the MS treats existent call 1 using 
BTS1 as represented in part (a) of Figure 777, TACFa in the base station controller 
ascertains radio resources occupied by existent call 1 and all available radio resources 
in all of the base stations (BTS1 and BTS2 in Figure 777) where the MS visits. 

Then, TACFa determines how to treat all calls, including the new call, for the 
MS on the basis of the ascertainment. In other words, TACFa in the base station 
controller determines to allocate the radio branch between the MS and BTS2 to calls 1 
and 2 as described above with reference to part (b) of Figure 777. According to the 
determination, the following steps are advanced in the system. 

(1) In order to request to establish an access link for existent call 1 via BTS2 
where the MS visits, TACFa sends a BEARER SETUP request indication to TACFv2- 
1 in the base station controller, which controls BTS2. 

(2) Upon the reception of the BEARER SETUP request indication, TACFv2-l 
sends a BEARER-AND-RADIO-BEARER SETUP request indication to BCFr2-l in 
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BTS2 to request to establish a radio access link between BTS2 and the MS and a wired 
access link between BTS2 and the base station controller for call 1. 

(3) Additionally, TACFa in the base station controller sends another BEARER 
SETUP request indication to TACFv2-2 in the base station controller, which controls 
BTS2 in order to request to establish an access link for new call 2 via BTS2 where the 
MS visits. 

(4) Upon the reception of the BEARER SETUP request indication, TACFv2-2 
sends another BEARER-AND-RADIO-BEARER SETUP request indication to BCFr2- 
2 in BTS2 to request to establish another radio access link between BTS2 and the MS 
and another wired access link between BTS2 and the base station controller for call 2. 

(5) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP request 
indication from TACFv2-l, BCFr2-l in BTS2 starts establishing the requested radio 
and wired access links, and then, sends a RADIO BEARER SETUP PROCEEDING 
request indication to TACFv2-l in the base station controller to report that the access 
link setup is proceeding. 

(6) Upon the reception of the RADIO BEARER SETUP PROCEEDING request 
indication, TACFv2-l sends a RADIO BEARER SETUP REQUEST request indication 
to TACFa to request to establish the radio access link for existent call 1 between the 
MS and BTS2. 

(7) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP request 
indication from TACFv2-2, BCFr2-2 in BTS2 starts establishing the requested radio 
and wired access links, and then, sends a RADIO BEARER SETUP PROCEEDING 
request indication to TACFv2-2 in the base station controller to report that the access 
link setup is proceeding. 

(8) Upon the reception of the RADIO BEARER SETUP PROCEEDING request 
indication, TACFv2-2 sends another RADIO BEARER SETUP REQUEST request 
indication to TACFa to request to establish the radio access link for new call 2 between 
the MS and BTS2. 
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(9) TACFa sends a single message including contents of a NON-SOFT 
HANDOVER EXECUTION request indication and of a RADIO BEARER SETUP 
request indication to TACAFa in the MS. The NON-SOFT HANDOVER BRANCH 
EXECUTION request indication is used for requesting to replace the existent radio 
access link via BTSl with the new branch via BTS2 for existent call 1. The 
HANDOVER BRANCH ADDITION request indication is used for establishing the 
radio access link via BTSl for call 2. 

(10) Subsequently, the MS starts to synchronize process of the MS with process of 
the BTS2 with respect to the new radio access link for existent call 1. 

(11) Furthermore, the MS starts to synchronize process of the BTS2 with process of 
the MS with respect to the new radio access link for new call 2. 

(12) After completion of the synchronization for call 1, BCFr2-l in BTS2 sends a 
BEARER- AND-RADIO-BEARER SETUP response confirmation to TACFv2-l in the 
base station controller to report the completion of the synchronization on the radio 
access link. 

(13) After completion of the synchronization for call 2, BCFr2-2 in BTS2 sends 
another BEARER- AND-RADIO-BEARER SETUP response confirmation to TACFv2-2 
in the base station controller to report the completion of the synchronization on the 
radio access link. 

(14) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 
confirmation from BCFr2-l, TACFv2-l sends a BEARER SETUP response 
confirmation to TACFa in the base station controller in order to report that the 
establishment of the radio access link via BTS2 for existent call 1 is completed. 

(15) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 
confirmation from BCFr2-2, TACFv2-2 sends another BEARER SETUP response 
confirmation to TACFa in the base station controller in order to report that the 
establishment of the other radio access link via BTS2 for new call 2 is completed. 

(16) TACFa thus receives two BEARER SETUP response confirmations from 
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TACFv2-l and TACFv2-2. Then, it sends a BEARER RELEASE request indication to 
TACFvl-1 for requesting the former or existent access link for call 1. 

(17) Upon the reception of the BEARER RELEASE request indication, TACFvl-1 
sends a BEARER-AND-RADIO-BEARER RELEASE request indication to BCFrl-1 for 
requesting to release the former access link via BTS1 for call 1. 

(18) Upon the reception of the BEARER-AND-RADIO-BEARER RELEASE 
request indication, BCFrl-1 releases the former access link via BTSl for call 1, and 
then, sends a BEARER-AND-RADIO-BEARER RELEASE response confirmation to 
report the completion of the access link release. 

(19) Next, TACFvl-1 in BTSl sends a BEARER RELEASE response confirmation 
to TACFa in the base station controller to report the completion of the access link 
release. Accordingly, the MS treats calls 1 and 2 using the new branch via BTS2 and 
frequency £2. 

3.7 FIRST METHOD FOR CONTROLLING BRANCH STRUCTURE 

AND FREQUENCY BAND WHEN A HANDOVER INITIATION 
OCCURS WHILE MOBILE STATION TREATS A PLURALITY 
OF CALLS 

3.7.1 BACKGROUND OF INVENTION OF THE METHOD 

The method described below is intended to resolve a problem involved in a 
mobile station which can treats a plurality of calls simultaneously. It is possible that 
a handover initiation occurs for this kind of mobile station while it treats a plurality of 
calls. In this case, it is possible that different branch structures and different 
frequency bands are allocated to the calls, respectively, if handover control for each call 
is independently carried out. Thus, it is necessary for the network to control 
respective calls with regard to handover of mobile station and transmission power, so 
that the network should endure an enormous burden with respect to preparation of 
overheads of messages. The control method described below will resolve the above- 
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mentioned problems. 



3.7.2 



EMBODYING METHOD 



5 



;i io 



ru is 

ru 



20 



25 



In accordance with an method according to an embodiment of the present 
invention, when a trigger of handover occurs to the mobile station which is treating a 
plurality of calls for the reason of the travelling of the mobile station or other 
situations, a branch structure or a communication frequency band which can continue 
all of the calls is selected, and the selected branch structure or communication 
frequency band are assigned to all of the calls commonly. 

Figure 780 is a diagram representing an embodying method. As represented 
in part (a) of Figure 780, an MS treats calls 1 and 2 at frequency fl using diversity 
handover branch structure including a branch between the MS and BTS1 and a 
branch between the MS and BTS2. Assume that the MS moves toward BTS3, so as to 
be capable of communicating with BTS3 at frequency fl. In addition, assume that the 
capacity of BTS3 is sufficient, so that it is possible to establish radio accesses between 
the MS and BTS3 for both calls 1 and 2. 

Accordingly, in the embodying method, handover is carried out such that the 
branch between the MS and BTS3 is added to the current branch structure and such 
that calls 1 and 2 are treated by the branch structure including the branch between 
the MS and BTS1; the branch between the MS and BTS2; and the branch between the 
MS and BTS3 as represented in part (b) of Figure 780. 

Figure 781 is a diagram representing another embodying method. As 
represented in part (a) of Figure 781, an MS treats calls 1 and 2 at frequency fl using a 
branch between the MS and BTS1. Assume that the MS is departing from the radio 
zone of BTS1 and comes near BTS3, so that it is necessary to add a branch between the 
MS and BTS3 for the MS. In addition, assume that the capacity of BTS3 is sufficient, 
so that it is possible to establish radio accesses between the MS and BTS3 for both 
calls 1 and 2. 
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However, BTS3 uses a frequency band f2, which is different from that of BTSl, 
so that the MS cannot conduct diversity reception by BTSl and BTS2. Therefore, in 
the embodying method, the branch structure is replaced with BTS3 for both calls 1 and 
2 as represented in part (b) of Figure 781. 

Figure 782 is a sequential flow diagram representing the operation 
exemplified in Figure 780 of the system. In Figure 782, TACAFa designates a 
functional entity in the MS shown in Figure 780. TACFa designates a functional 
entity in the base station controller generated first after the MS has started 
communication. TACFv3-l and TACFv3-2 designate instances of functional entities 
in the base station controller in order that the base station controller controls BTS3 
where the MS visits. TACFv3-l and TACFv3-2 correspond to calls 1 and 2, 
respectively. BCFr3-l and BCFr3-2 designate instances of functional entities in 
BTS3 for controlling radio resources. BCFr3-l and BCFr3-2 correspond to calls 1 and 
2, respectively. The subject method for transiting from the state of part (a) to the 
state of part (b) in Figure 780 will be described with reference to Figure 782. 

(1) TACFa in the base station controller sends a BEARER SETUP request 
indication to TACFv3-l in the base station controller corresponding to BTS3 in order to 
establish an access link between BTS3 and the MS for call 1. 

(2) Upon the reception of the BEARER SETUP request indication, TACFv3-l 
sends a BEARER-AND-RADIO-BEARER SETUP request indication to BCFr3-l in 
BTS3 to request to establish a radio access link between BTS3 and the MS and a wired 
access link between BTS3 and the base station controller for call 1. 

(3) In addition, TACFa in the base station controller sends another BEARER 
SETUP request indication to TACFv3-2 in the base station controller corresponding to 
BTS3 in order to establish another access link between BTS3 and the MS for call 2. 

(4) Upon the reception of the BEARER SETUP request indication, TACFv3-2 
sends a BEARER-AND-RADIO-BEARER SETUP request indication to BCFr3-2 in 
BTS3 to request to establish another radio access link between BTS3 and the MS and 
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another wired access link between BTS3 and the base station controller for call 2. 

(5) In accordance with the BEARER-AND-RADIO-BEARER SETUP request 
indication from TACFv3-l, BCFr3-l in BTS3 establishes the requested radio and wired 
access links for call 1, and then, sends a BEARER-AND-RADIO -BEARER SETUP 
response confirmation to TACFv3-l in the base station controller to report that the 
access link setup is completed. 

(6) Upon the reception of the BEARER- AND -RADIO-BEARER SETUP response 
confirmation, TACFv3-l sends a RADIO BEARER SETUP REQUEST request 
indication to TACFa to request to establish the radio access link for call 1 between the 
MS and BTS3. 

(7) In accordance with the BEARER-AND-RADIO -BEARER SETUP request 
indication from TACFv3-2, BCFr3-2 in BTS3 establishes the requested radio and wired 
access links for call 2, and then, sends another BEARER-AND-RADIO -BEARER 
SETUP response confirmation to TACFv3-2 in the base station controller to report that 
the access link setup is completed. 

(8) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 
confirmation, TACFv3-2 sends another RADIO BEARER SETUP REQUEST request 
indication to TACFa to request to establish the radio access link for call 2 between the 
MSandBTS3. 

(9) Then, TACFa sends a HANDOVER BRANCH ADDITION request indication 
to TACAFa in the MS to additionally establish a new radio access link between BTS3 
and the MS for calls 1 and 2 without releasing the formerly used radio access links via 
BTS1 and BTS2 for calls 1 and 2. 

(10) In accordance with the HANDOVER BRANCH ADDITION request indication, 
TACAFa completes to establish the additional radio access link between BTS3 and the 
MS for calls 1 and 2. TACAFa in the MS then sends a HANDOVER BRANCH 
ADDITION response confirmation to TACFa in the base station controller for notifying 
of the completion. Consequently, the MS uses the diversity handover branch 
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structure including the branches via BTSl, BTS2, and BTS3 for treating both calls 1 
and 2. 

Figure 783 is a sequential flow diagram representing the operation 
exemplified in Figure 781 of the system. In Figure 783, TACAFa designates a 
functional entity in the MS shown in Figure 781. TACFa designates a functional 
entity in the base station controller generated first after the MS has started 
communication. TACFvl-1 and TACFvl-2 designate instances of functional entities 
in the base station controller in order that the base station controller controls BTSl. 
TACFvl-1 and TACFvl-2 correspond to calls 1 and 2, respectively. TACFv3-l and 
TACFv3-2 designate instances of functional entities in the base station controller in 
order that the base station controller controls BTS3. TACFv3-l and TACFv3-2 
correspond to calls 1 and 2, respectively. BCFrl-1 and BCFrl-2 designate instances 
of functional entities in BTSl for controlling radio resources. BCFrl-1 and BCFrl-2 
correspond to calls 1 and 2. BCFr3-l and BCFr3-2 designate instances of functional 
entities in BTS3 for controlling radio resources. BCFr3-l and BCFr3-2 correspond to 
calls 1 and 2, respectively. The subject method for transiting from the state of part (a) 
to the state of part (b) in Figure 781 will be described with reference to Figure 783. 

(1) TACFa in the base station controller sends a BEARER SETUP request 
indication to TACFv3-l in the base station controller corresponding to BTS3 in order to 
establish an access link between BTS3 and the MS for call 1. 

(2) Upon the reception of the BEARER SETUP request indication, TACFv3-l 
sends a BEARER- AND-RADIO-BEARER SETUP request indication to BCFr3-l in 
BTS3 to request to establish a radio access link between BTS3 and the MS and a wired 
access link between BTS3 and the base station controller for call 1. 

(3) In addition, TACFa in the base station controller sends another BEARER 
SETUP request indication to TACFv3-2 in the base station controller corresponding to 
BTS3 in order to establish another access link between BTS3 and the MS for call 2. 

(4) Upon the reception of the BEARER SETUP request indication, TACFv3-2 
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sends a BEARER-AND-RADIO-BEARER SETUP request indication to BCFr3-2 in 
BTS3 to request to establish another radio access link between BTS3 and the MS and 
another wired access link between BTS3 and the base station controller for call 2. 

(5) In accordance with the BEARER-AND-RADIO-BEARER SETUP request 
5 indication from TACFv3-l, BCFr3-l in BTS3 starts to establish the requested radio 

and wired access links for call 1, and then, sends a BEARER-AND-RADIO-BEARER 
SETUP PROCEEDING request indication to TACFv3-l in the base station controller 
to report that the access link setup is proceeding. 

(6) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP 
10 PROCEEDING request indication, TACFv3-l sends a RADIO BEARER SETUP 

REQUEST request indication to TACFa in the base station controller to request to 
establish the radio access link for call 1 between the MS and BTS3. 

(7) In accordance with the BEARER-AND-RADIO-BEARER SETUP request 
indication from TACFv3-2, BCFr3-2 in BTS3 starts to establish the requested radio 

15 and wired access links for call 2, and then, sends another BEARER-AND-RADIO- 
BEARER SETUP PROCEEDING request indication to TACFv3-2 in the base station 
controller to report that the access link setup is proceeding. 

(8) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP 
PROCEEDING request indication from BCFr3-2, TACFv3-2 sends another RADIO 

20 BEARER SETUP REQUEST request indication to TACFa to request to establish the 
radio access link for call 2 between the MS and BTS3. 

(9) Upon the reception of the second RADIO BEARER SETUP REQUEST request 
indication, TACFa sends a NON-SOFT HANDOVER EXECUTION request indication 
to TACAFa in the MS to request to replace the radio access link via BTS1 with the 

25 radio access link via BTS3 for both calls 1 and 2. 

(10) In accordance with the NON-SOFT HANDOVER EXECUTION request 
indication, TACAFa in the MS replaces the radio access link, and starts to synchronize 
process of the mobile station with process of BTS3 for call 1 with respect to the new 
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radio access link. 

(11) Furthermore, the MS starts to synchronize process of the mobile station with 
process of BTS3 for call 2 with respect to the new radio access link. 

(12) After completion of the synchronization for call 1, BCFr3-l in BTS3 sends a 
BEARER-AND-RADIO-BEARER SETUP response confirmation to TACFv3-l in the 
base station controller to report the completion of the synchronization on the radio 
access link. 

(13) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 
confirmation from BCFr3-l, TACFv3-l sends a BEARER SETUP response 
confirmation to TACFa in order to report the completion of the access link setup. 

(14) On the other hand, after completion of the synchronization for call 2, BCFr3-2 
in BTS3 sends another BEARER-AND-RADIO-BEARER SETUP response 
confirmation to TACFv3-2 in the base station controller to report the completion of the 
synchronization oh the radio access link. 

(15) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 
confirmation from BCFr3-2, TACFv3-2 sends another BEARER SETUP response 
confirmation to TACFa in order to report the completion of the access link setup. 

(16) TACFa thus receives two BEARER SETUP response confirmations from 
TACFv3-l and TACFv3-2. Then, it sends a BEARER RELEASE request indication to 
TACFvl-1 for requesting the former or existent access link for call 1. 

(17) Upon the reception of the BEARER RELEASE request indication, TACFvl-1 
sends a BEARER-AND-RADIO-BEARER RELEASE request indication to BCFrl-1 for 
requesting to release the former access link via BTS1 for call 1. 

(18) Upon the reception of the BEARER-AND-RADIO-BEARER RELEASE 
request indication, BCFrl-1 releases the former access link via BTS1 for call 1, and 
then, sends a BEARER-AND-RADIO-BEARER RELEASE response confirmation to 
TACFvl-1 to report the completion of the access link release. 

(19) Next, TACFvl-1 in BTSl sends a BEARER RELEASE response confirmation 
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to TACFa in the base station controller to report the completion of the access link 
release. 

Furthermore, as represented in Figure 783, the processes similar to steps (16) 
through (19) are executed for call 2 from step (20) to (23). Consequently, the MS uses 
the single branch between the MS and BTS3 for treating both calls 1 and 2. 

3.8 SECOND METHOD FOR CONTROLLING BRANCH STRUCTURE 

AND FREQUENCY BAND WHEN A HANDOVER INITIATION 
OCCURS WHILE MOBILE STATION TREATS A PLURALITY 
OF CALLS 

3.8. 1 BACKGROUND OF INVENTION OF THE METHOD 

In accordance with the method described at section 3.7, when a trigger of 
handover occurs to the mobile station which is treating a plurality of calls, a branch 
structure or a communication frequency band which can continue all of the calls is 
selected, and the selected branch structure or communication frequency band are 
assigned to all of the calls commonly. 

However, it may be impossible to allocate radio resources of the newly visited 
base station to all calls for the mobile station because of insufficiency of capacity of the 
base station. In this case, if no countermeasure is taken, all calls should be released. 

However, priorities of calls are not necessarily the same as each other: it is 
possible that a call is an emergency call. Although all calls cannot be maintained, one 
or more calls being high in priority can be sometimes maintained such that radio 
resources can be allocated to them. In this case, release of all calls is not reasonable. 

The control method described below will resolve the above-mentioned 
problems. 



3.8.2 EMBODYING METHOD 

In accordance with a method of an embodiment of the present invention, when 
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a trigger of handover occurs to the mobile station which is treating a plurality of calls 
for the reason of the travelling of the mobile station or other situations, the handover 
is carried out as follows: 

a. A mobile station or a device (e.g., base station controller) in the network 
5 determines whether or not there is a branch structure or a frequency band for 

continuing all calls. 

b. When there is not a branch structure which can continue all of the calls or 
there is not a frequency band which can continue all of the calls, the mobile station or 
the device recognizes the idle capacity of the newly visited base station available for 

10 the mobile station. 

c. One or more calls among the treated calls are selected in accordance with 
priority so that the calls being high in priority can be maintained by the idle capacity. 
The other calls are released. When a plurality of calls have the same priority, all calls 
are released or one or more are selected in accordance with another fashion (e.g., by 

15 random selection or in accordance with the length of the connecting time) and the 
others are released. 

d. The selected call or calls are handed over to the new branch or the frequency 
in relation to the idle capacity. 

According to the control method, the call(s) of low priority is released to 
20 continue the call(s) of high priority, and the handover is carried out for the priority 
call(s) such that priority calls utilize a common branch structure and a common 
frequency band if a plurality of priority calls are selected to be continued. 

Figure 784 is a diagram representing an embodying method. In part (a) of 
Figure 784, an MS uses a branch at frequency fl between BTS1 and the MS, thereby 
25 treating calls 1 and 2. The MS is travelling from the radio zone corresponding to 
BTS1 to the radio zone corresponding to BTS3 and the MS should be handed over from 
BTS1 to BTS3 at this time. 

However, the capacity of the BTS3 is too insufficient to continue both calls 1 
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and 2. More specifically, it will be possible to continue only call 1 of high priority. In 
addition, the frequency f2 is used by BTS3, so that it is impossible to carry out 
diversity handover from BTSl to BTS3. 

Accordingly, call 2 being low in priority for the MS is released and call 1 of 
5 high priority is controlled to remain and is handed over from the branch via BTSl to 
the branch via BTS3 as represented in part (b) of Figure 784 in the embodiment. 

Figure 785 is a sequential flow diagram representing the operation 
exemplified in Figure 784 of the system. In Figure 785, meanings of TACAFa, 
TACFvl-1, and so on are the same as those in Figure 783. The subject method for 
S 10 transiting from the state illustrated in part (b) to the state illustrated in part (a) of 

h Figure 784 will be described with reference to Figure 785. 

S (1) TACFa in the base station controller sends a BEARER SETUP request 

;i f indication to TACFv3-l in the base station controller corresponding to BTS3 in order to 

^ establish an access link between BTS3 and the MS for call 1. 

U 15 (2) Upon the reception of the BEARER SETUP request indication, TACFv3-l 

ij sends a BEARER-AND-RADIO-BEARER SETUP request indication to BCFr3-l in 

3 BTS3 to request to establish a radio access link between BTS3 and the MS and a wired 

access link between BTS3 and the base station controller for call 1. 

(3) In. addition, TACFa in the base station controller sends a BEARER RELEASE 
20 request indication to TACFvl-2 in the base station controller corresponding to BTSl 

for requesting the access link for lower priority call 2. 

(4) Upon the reception of the BEARER RELEASE request indication, TACFvl-2 
sends a BEARER-AND-RADIO-BEARER RELEASE request indication to BCFrl-2 in 
BTSl for requesting to release the radio access link between BTSl and the MS and the 

25 wired access link between BTSl and the base station controller for call 2. 

(5) On the other hand, in accordance with the BEARER-AND-RADIO-BEARER 
SETUP request indication from TACFv3-l, BCFr3-l in BTS3 starts to establish the 
requested radio and wired access links for call 1, and then, sends a BEARER-AND- 



F0220/2551 




367 

RADIO-BEARER SETUP PROCEEDING request indication to TACFv3-l in the base 
station controller to report that the access link setup is proceeding. 

(6) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP 
PROCEEDING request indication, TACFv3-l sends a RADIO BEARER SETUP 
REQUEST request indication to TACFa in the base station controller to request to 
establish the radio access link for call 1 between the MS and BTS3. 

(7) Upon the reception of the BEARER-AND-RADIO-BEARER RELEASE 
request indication, BCFrl-2 releases the access link for call 2 via BTSl for call 1, and 
then, sends a BEARER-AND-RADIO-BEARER RELEASE response confirmation to 
TACFvl-2 to report the completion of the access link release for call 2. 

(8) Upon the reception of the BEARER-AND-RADIO-BEARER RELEASE 
response confirmation, TACFvl-2 in BTSl sends a BEARER RELEASE response 
confirmation to TACFa in the base station controller to report the completion of the 
access link release for call 2. 

(9) Upon the reception of the BEARER-AND-RADIO-BEARER RELEASE 
response confirmation, TACFa sends a NON-SOFT HANDOVER EXECUTION 
request indication to TACAFa in the MS to request to replace the radio access link via 
BTSl with the radio access link via BTS3 for the MS. 

(10) In accordance with the NON-SOFT HANDOVER EXECUTION request 
indication, TACAF a in the MS replaces the radio access link, and starts to synchronize 
process of the mobile station with process of BTS3 for call 1 with respect to the new 
radio access link. 

(11) After completion of the synchronization for call 1, BCFr3-l in BTS3 sends a 
BEARER-AND-RADIO-BEARER SETUP response confirmation to TACFv3-l in the 
base station controller to report the completion of the synchronization on the radio 
access link. 

(12) Upon the reception of the BEARER-AND-RADIO-BEARER SETUP response 
confirmation from BCFr3-l, TACFv3-l sends a BEARER SETUP response 
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confirmation to TACFa in order to report the completion of the access link setup. 

(13) Upon the reception of the BEARER SETUP response confirmation from 
TACFv3-l, TACFa sends another BEARER RELEASE request indication to TACFvl-1 
for requesting the former and unnecessary access link for call 1. 

(14) Upon the reception of the BEARER RELEASE request indication, TACFvl-1 
sends a BEARER- AND-RADIO-BEARER RELEASE request indication to BCFrl-1 for 
requesting to release the former access link via BTS1 for call 1. 

(15) Upon the reception of the BE ARER-AND-RADIO -BEARER RELEASE 
request indication, BCFrl-1 releases the former access link for call 1 via BTSl for call 
1, and then, sends a BEARER-AND-RADIO-BEARER RELEASE response 
confirmation to report the completion of the access link release. 

(16) Next, TACFvl-1 in BTSl sends a BEARER RELEASE response confirmation 
to TACFa in the base station controller to report the completion of the access link 
release for call 1. Consequently, only call 1 of high priority is continued by the use of 
the branch via BTS3. 

3-9 METHOD FOR HANDOVER WHEREIN THE BRANCH ADDITION 

PROCEDURE IS COMPLETED WITHOUT CONFIRMATION OF 
SYNCHRONIZATION OF BRANCHES 

3.9. 1 BACKGROUND OF INVENTION OF THE METHOD 

In conventional mobile communications system, a handover branch addition 

procedure is carried out as follows: 

(1) A new branch is additionally established between the mobile station and a 
new base station. 

(2) The new base station confirms that the receiving process in the base station is 
synchronized with the radio signals from the mobile station. 

(3) The new base station reports to the base station controller about the 
completion of the synchronization. 
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(4) The branch addition procedure is completed. 

However, as described above, a necessary communication quality is sometimes 
obtained by a plurality of branches including one or more auxiliary branches added on 
demand in the present system although minimal transmission power is consumed. In 
5 this structure, it is not limited that each branch satisfies the necessary level of the 
quality. Therefore, sometimes it is impossible to execute synchronization with respect 
to an auxiliary branch for which the transmission power is low. 

Accordingly, if the conventional handover branch addition procedure including 
above-described steps (1) through (4) is applied to the present system, there is 
10 likelihood that it is impossible to confirm the synchronization with respect to a new 
branch and the branch addition procedure is continued for an unnecessarily long time. 
The method described below resolves the problems. 

3.9.2 EMBODYING METHOD 

15 In accordance with the present system, the handover branch addition 

procedure is completed upon the onset of communicating a layer 3 message without 
waiting for the confirmation of synchronization for a newly added branch. 

Consequently, the base station controller finishes the handover branch 
addition procedure without waiting for the confirmation of synchronization for the 

20 newly added branch although it sends SETUP request indications for the new branch 
to the base station and mobile station. 

Upon the reception of the setup request for the new branch, the mobile station 
adapts the interior functions and the communication frequency to the new branch, so 
as to enter the state for receiving signals from the new branch. Then, once the mobile 

25 station receives a meaningful signal from the branch, the mobile station starts the 
diversity combining using with signals received from the new branch and another 
branch since the new branch can be considered to be established. 

Similarly, upon the reception of the setup request for the new branch, the base 
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station adapts the interior functions and the communication frequency to the new 
branch, so as to enter the state for receiving signals from the new branch. Then, once 
the base station receives a meaningful signal from the branch, the base station starts 
to transmit signals via the new branch since it can be considered to be established. At 
5 the same time, the base station starts the diversity combining using with signals 
received from the new branch and another branch if the base station conducts intra- 
cell diversity handover. Alternatively, the base station starts to transfer signals 
received from the new branch to the base station controller so that the base station 
controller can start the diversity combining using with signals from the base station 
10 and another base station if the base station controller conducts inter-cell diversity 
handover. 

The above- described method is applied into various control methods which 
have been already described before this section. For example, Figure 41 is an 
information flow diagram of the inter-sector handover branch addition in a single cell 

15 while Figure 43 is an information flow diagram of the inter-cell handover branch 
addition. In the branch addition procedures in the diagrams, once layer 1 connection 
is established, the mobile station can communicate. Accordingly, the network finishes 
the branch addition procedure without waiting for the confirmation of synchronization 
for the newly added auxiliary branch. 

20 Figure 770 is a sequential flow diagram representing the start of inter-cell 

diversity handover simultaneously with the access link setup. In this procedure, the 
mobile station can start communicating layer 3 messages once the synchronization on 
layer 1 about the main branch between TACAFa and BCFrl is completed. Therefore, 
the handover procedure is ended without waiting for the confirmation of 

25 synchronization for the auxiliary branch between TACAFa and BCFr2. 

Figure 773 is a sequential flow diagram representing an operation in the 
invented system which is carried out when the mobile station moves to a diversity 
handover zone. In this procedure, the mobile station can start communicating. layer 3 
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messages once the synchronization on layer 1 about the new main branch between 
TACAFa and BCFr2 is completed after the branch replacement. Therefore, the 
handover procedure is ended without waiting for the confirmation of synchronization 
for the auxiliary branch between TACAFa and BCFr3. 
5 The same is applied to other diversity handover procedures illustrated in 

Figures 775, 778, and so on. 

3. 10 METHOD FOR CONTROLLING MANAGEMENT OF 

CODE RESOURCES 
10 3.10.1 BACKGROUND OF INVENTION OF THE METHOD 

In a usual method for controlling management of code resources, code 
resources are reassigned (calls are rearranged) when a call is originated or ended. 
However, if code resources are reassigned upon a call occurrence, a long delay of the 
link establishment occurs. If code resources are reassigned at the end of a call, the 
15 control for the reassignment is redundant and causes the increase of a control burden. 

There is a mobile communications system wherein an assignable code 
resource can be divided into a plurality of code resources, and any of the original code 
resource and the divided code resources can be selected in accordance with the length 
corresponding to a necessary bandwidth and be assigned to a call. In this system, 
20 when the divided code resources are repeated to be assigned and released blithely, the 
fragmented assignable code resources are dispersed in the code resource space. In 
order to broaden the bandwidth, an unused code resource having the length 
corresponding to the necessary bandwidth should be reserved. 

Therefore, reassignment of code resources to calls is necessary for rearranging 
25 the fragments to reserve unused code resources corresponding to wide bandwidth^ 

However, if code resources are reassigned upon a call occurrence, a long delay 
of the link establishment occurs. If code resources are reassigned at the end of a call, 
the control for the reassignment is redundant and causes the increase of a control 
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burden since the next call is not necessarily a wide band call. 

The selection of trigger timing for reassigning code resources (for rearranging 
calls) is an important consideration for improving operability and reducing the system 
burden. 

5 It is an object of the mobile communications system, base station, base station 

controller, and method for controlling thereof to optimize the trigger timing for 
reassigning code resources, to reduce the number of reassignments, and to minimize 
the delay of the link setup. 

10 3.10.2 EMBODYING METHOD 

Figure 793 represents a state where code resources have been assigned to 
channels. In the state illustrated in Figure 793, only code resources CR5-2, CR5-7, 
CR5-8, CR5-9, CR5-11, CR5-15, and CR5-16 are not used nor assigned, but available 
with respect to level 5 since nodes upper than the available code resources are not 

15 used. 

In addition, with respect to upper levels, a code resource at a node is available 
if all of the lower leaves and the upper node are not used. More specifically, with 
respect to a node Nl, the lower leaves CR5 - 15 and CR5-16 and the upper node N2 are 
not used, so that the code resource CR4-8 at the node Nl is available. 

20 The reason for the above-mentioned characteristics is because any upper code 

resource is divided into lower code resources. Therefore, the bandwidth relationship 
can be expressed by the following equation. 

WCR1 = 2 x (WCR2) = 4 x (WCR3) = 8 x (WCR4) = 16 x (WCR5) 
where WCR1 is the bandwidth corresponding to the code resource CR1 at level 1, 

25 WCR2 is the bandwidth corresponding to code a resource CR2 at level 2, WCR3 is the 
bandwidth corresponding to code a resource CR3 at level 3, WCR4 is the bandwidth 
corresponding to code a resource CR4 at level 4, and WCR5 is the bandwidth 
corresponding to code a resource CR5 at level 5. Therefore, for example, the 
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bandwidth WCR4 corresponding to a code resource CR4 at level 4 can be utilized by 
two code resources CR5 at level 5. 

In the state shown in Figure 793, it is impossible to reserve a code resource 
CR3 at level 3 which may be divided into four code resources CR5 at level 5 although 
there are seven unused code resources CR5-2, CR5-7, CR5-8, CR5-9, CR5-11, CR5-15, 
and CR5-16 at level 5. The reasons are because all code resources CR3-1 through 
CR3-4 are independent of one another and any successive code resource cannot be 
assembled from parts of respective code resources CR3-1 through CR3-4, and at least a 
part of each of code resources CR3-1 through CR3-4 have been already used at the 
lower levels. 

In order to use a code resource CR3 at level 3, it is necessary to use other code 
resources instead of the used code resources at levels 4 or 5 below the subject code 
resource CR3 as represented in Figure 794. 

For this purpose, the radio base station determines whether a code resource 
corresponding to a necessary bandwidth can be availed or not; The base station 
controller reassigns the code resources on the bases of the determination. 

More specifically, when the radio base station determines that code resource 
CR3-4 cannot be reserved, the base station controller assigns the unused code resource 
CR5-9 instead of the used code resource CR5-11 being of the same length at step Si. 
In addition, the base station controller assigns the unused code resource CR4-7 instead 
of the used code resource CR4-6 being of the same length at step S2. Thus, the code 
resource CR3-4 can be reserved. 

As described above, the selection of trigger timing for reassigning code 
resources (for rearranging calls) is an important consideration for reducing the system 
burden. In the embodying method, once all available code resources corresponding to 
a preselected bandwidth are assigned, the reassignment is started. 

More specifically, assume that the code resource CR3 at level 3 is selected as a 
standard code resource that is the longest assignable code resource corresponding to 



F0220/2551 



374 

the usable widest bandwidth. Simultaneously, the bandwidth corresponding to the 
code resource CR3 at level 3 is selected as a standard bandwidth. Once all standard 
code resources CR3 cannot be assigned as represented in Figure 793, the reassignment 
of code resources is triggered as represented in Figure 794. Since the reassignment 
procedure is not carried out at the call occurrence, the delay of the link setup can be 
minimized. In addition, it is possible to reduce the control burden for the system in 
comparison with the case that the reassignment is always conducted at call release. 

As described above, it is possible to reduce the number of reassignments and 
to minimize the delay of the link setup, whereby service quality and operability given 
to the user can be improved. 



